做为Java开发，你真的了解系统吗？技术架构又要解决什么问题？

本文已收录GitHub，更有互联网大厂面试真题，面试攻略，高效学习资料等

对于开发人员来讲，咱们天天都在用技术。但你要知道，咱们写的代码，其实只是系统的一小部分，咱们了解的技术，也只是系统用到的一小部分。要深刻掌握技术架构，咱们就须要了解总体的系统。

面对一个复杂的系统，我想你可能常常会有如下困扰：

1. 不清楚系统总体的处理过程，当系统出问题时，不知道如何有针对性地去排查问题。
2. 系统设计时，常常忽视非业务性功能的需求，也不清楚如何实现这些目标，常常是付出惨痛的教训后，才去亡羊补牢。

不知你是否还记得，在以前的文章中，我已经说过，技术架构是从物理层面定义系统，并保障系统的稳定运行。那么今天，我会先分析下系统在物理上由哪些部分组成，让你能够从全局的角度看一个系统；而后再和你一块儿讨论，技术架构会面临哪些软硬件的挑战，以及它都有哪些目标，让你可以深刻地了解技术架构。

系统的物理模型

对于大部分开发人员来讲，咱们主要的工做是写业务相关的代码，保证业务逻辑正确、业务数据准确，而后，这些业务代码通过打包部署后，变成实际可运行的应用。但咱们写的代码只是系统的冰山一角，为了保证应用能正常运行，咱们须要从端到端系统的角度进行分析。

咱们先看下一个系统的具体组成，这里我为你提供了一个简化的系统物理模型，你能够了解一个系统大体包含哪些部分。

从用户请求的处理过程来看，系统主要包括五大部分。

首先是接入系统，它负责接收用户的请求，而后把用户的请求分发到某个 Web 服务器进行处理，接入系统主要包括 DNS 域名解析、负载均衡、Web 服务器这些组件。

接下来，Web 服务器会把请求交给应用系统进行处理。通常来讲，咱们是基于某个开发框架来开发应用的，好比 Java 应用通常是基于 Spring MVC 框架。

这个时候，开发框架首先会介入请求的处理，好比对 HTTP 协议进行解析，而后根据请求的 URL 和业务参数，转给咱们写的业务方法。接下来，咱们的应用代码，会调用开发语言提供的库和各类第三方的库，好比 JDK 和 Log4j，一块儿完成业务逻辑处理。在这里，咱们会把开发框架、应用代码，还有这些库打包在一块儿，组成一个应用系统，做为独立的进程在Web 服务器中进行部署和运行。

到这里，整个系统要作的事情就完了吗？

尚未呢，在咱们的应用系统底下，还有基础平台，它由好几个部分组成：首先是各个语言的运行时，好比说 JVM；而后是容器或虚拟机；下面还有操做系统；最底下就是硬件和网络。

接入系统、应用系统、基础平台就构成一个最简单的系统。

在大多数状况下，应用系统还要借助大量外部的中间件来实现功能和落地数据，好比数据库、缓存、消息队列，以及 RPC 通信框架等等。这里，我统称它们为核心组件，它们也是系统不可缺乏的一部分。

除此以外，还有大量周边的支撑系统在支持应用的正常运行，包括日志系统、配置系统，还有大量的运维系统，它们提供监控、安全、资源调度等功能，它们和核心组件的区别是，这些系统通常不参与实际的用户请求处理，但它们在背后默默保障系统的正常运行。

到这里，你能够发现，一个端到端的系统是很是复杂的，它包含了大量的软硬件。为了保障咱们的应用代码可以正常运行，咱们就须要保证这里的每一个组件不出问题，不然一旦组件出问题，极可能就致使系统总体的不可用。

技术架构的挑战

应用代码怎么组织（好比模块划分和服务分层），那主要是业务架构的事，这部分在前面咱们已经讨论过不少了；而技术架构的职责，首先是负责系统全部组件的技术选型，而后确保这些组件能够正常运行。

咱们知道，系统是由硬件和软件组成的。接下来，咱们就分别从软硬件的角度来看下，技术架构都会面临什么挑战，咱们须要如何应对。

硬件的问题

硬件是一个系统最基础的部分，负责真正干活的，但它有两方面的问题。

首先是硬件的处理能力有限。对于服务器来讲，它的 CPU 频率、内存容量、磁盘速度等等都是有限的。虽说按照摩尔定律，随着制造工艺的发展，大概每隔 18 个月，硬件的性能

能够提高一倍，但仍是赶不上快速增加的系统处理能力的要求，特别是目前许多互联网平台，面向的都是海量的 C 端用户，对系统处理能力的要求能够说是没有上限的。

从技术架构的角度，提高硬件的处理能力通常有两种方式。

Scale Up

也就是垂直扩展，简单地说就是经过升级硬件来提高处理能力。CPU 不够快，升级内核数量；内存不够多，升级容量；网络带宽不够，升级带宽。因此说，Scale Up 其实是提高硬件的质量。

Scale Out

也就是水平扩展，经过增长机器数量来提高处理能力。一台机器不够，就增长到 2 台、4台，以及更多，经过大量廉价设备的叠加，加强系统总体的处理能力。因此说，Scale Out是提高硬件的数量。

垂直扩展是最简单的方式，对系统来讲，它看到的是一个性能更强的组件，技术架构上不须要任何改造。若是碰到性能有问题，垂直扩展是咱们的首选，但它有物理上的瓶颈或成本的问题。受硬件的物理限制，机器的性能是有天花板的；或者有时候，硬件超出了主流的配置，它的成本会指数级增加，致使咱们没法承受。

水平扩展经过硬件数量弥补性能问题，理论上能够应对全部服务器处理能力不足的状况，并实现系统处理能力和硬件成本保持一个线性增加的关系。

但水平扩展对于系统来讲，它看到的是多个组件，好比说多台 Web 服务器。如何有效地管理大量的机器，一方面，使得性能上能够实现相似 1+1=2 的效果；另外一方面，要让系统各个部分可以有效地衔接起来，稳定地运行，这不是一件容易的事情。咱们须要经过很复杂的技术架构设计来保障，好比说，经过额外的负载均衡，来支持多台 Web 服务器并行工做。

硬件的第二个问题是，硬件不是 100% 的可靠，它自己也会出问题。

好比说，服务器断电了，网络电缆被挖断了，甚至是各类天然灾害致使机房总体不可用。尤为是一个大型系统，服务器规模很大，网络很复杂，一旦某个节点出问题，整个系统均可能受影响，因此，机器数量变多，也放大了系统出故障的几率，致使系统总体的可用性变差。咱们在作技术架构设计时，就要充分考虑各类硬件故障的可能性，作好应对方案。好比说针对天然灾害，系统作异地多机房部署。

软件的问题

接下来咱们说下软件的问题，这里的软件，主要说的是各类中间件和系统级软件，它们配合咱们的应用代码一块儿工做。

软件是硬件的延伸，它主要是解决硬件的各类问题，软件经过进一步封装，给系统带来了两大好处。

• 首先是弥补了硬件的缺陷。好比 Redis 集群，经过数据分片，解决了单台服务器内存和带宽的瓶颈问题，实现服务器处理能力的水平扩展；经过数据多副本和故障节点转移，解决了单台服务器故障致使的可用性问题。
• 其次，封装让咱们能够更高效地访问系统资源。好比说，数据库是对文件系统的增强，使数据的存取更高效；缓存是对数据库的增强，使热点数据的访问更高效。

但软件在填硬件的各类坑的同时，也给系统挖了新的坑。举个例子，Redis 集群的多节点，它解决了单节点处理能力问题，但同时也带来了新的问题，好比节点内部的网络有问题（即网络分区现象），集群的可用性就有问题；Redis 数据的多副本，它解决了单台服务器故障带来的可用性问题，但同时也带来了数据的一致性问题。

咱们知道，分布式系统有个典型的 CAP 理论，C 表明系统内部的数据一致性，A 代码系统的可用性，P 表明节点之间的网络是否容许出问题，咱们在这三者里面只能选择两个。对于一个分布式系统来讲，网络出问题是比较常见的，因此咱们首先要选择 P，这意味着咱们在剩下的 C 和 A 之间只能选择一个。

CAP 理论只是针对一个小的数据型的分布式系统，若是放大到整个业务系统，C 和 A 的选择就更加复杂了。

好比有时候，咱们直接对订单进行写库，这是倾向于保证数据一致性 C，但若是数据库故障或者流量太大，写入不成功，致使当前的业务功能失败，也就是系统的可用性 A 产生了问题。若是咱们不直接落库，先发订单数据到消息系统，再由消费者接收消息进行落库，这样

即便单量很大或数据库有问题，最终订单仍是能够落地，不影响当前的下单功能，保证了系统的可用性，但可能不一样地方（好比缓存和数据库）的订单数据就有一致性的问题。

鱼和熊掌不能兼得，系统没法同时知足 CAP 的要求，咱们就须要结合具体的业务场景，识别最突出的挑战，而后选择合适的组件，并以合理的方式去使用它们，最终保障系统的稳定运行，不产生大的业务问题。

技术架构的目标

好，如今你已经了解了系统的复杂性和软硬件的问题，那技术架构就要选择和组合各类软硬件，再结合咱们开发的应用代码，来解决系统非功能性需求。

什么是系统非功能性需求呢？这是相对于业务需求来讲的，所谓的业务需求就是保证业务逻辑正确，数据准确。好比一个订单，咱们要保证订单各项数据是准确的，订单优惠和金额计算逻辑是正确的。而一个订单页面打开须要多少时间，页面是否是每次都能打开，这些就和具体的业务逻辑没有关系，属于系统非功能性需求的范畴。产品经理在通常状况下，也不会明确提这些需求。非功能性需求，有时候咱们也称之为系统级功能，和业务功能相区分。

那对于一个系统来讲，技术架构都要解决哪些非功能性需求呢？

系统的高可用

可用性的衡量标准是，系统正常工做的时间除以整体时间，一般用几个 9 来表示，好比 3个 9 表示系统在 99.9% 的时间内可用，4 个 9 表示 99.99% 的时间内可用，这里的正常工做表示系统能够在相对合理的时间内返回预计的结果。

致使系统可用性出问题，通常是两种状况：

• 一种是软硬件自己有故障，好比机器断电，网络不通。这要求咱们要么及时解决当前节点的故障问题，要么作故障转移，让备份系统快速顶上。
• 还有一种是高并发引发的系统处理能力的不足，软硬件系统常常在处理能力不足时，直接瘫痪掉，好比 CPU 100% 的时候，整个系统彻底不工做。这要求咱们要么提高处理能力，好比采起水平扩展、缓存等措施；要么把流量控制在系统能处理的水平，好比采起限流、降级等措施。

系统的高性能

咱们这里说的高性能，并非指系统的绝对性能要多高，而是系统要提供合理的性能。好比说，咱们要保证前端页面能够在 3s 内打开，这样用户体验比较好。

保证合理的性能分两种状况：

• 一种是常规的流量进来，但系统内部处理比较复杂，咱们就须要运用技术手段进行优化。好比针对海量商品的检索，咱们就须要构建复杂的搜索系统来支持。
• 第二种是高并发的流量进来，系统仍旧须要在合理的时间内提供响应，这就更强调咱们作架构设计时，要保证系统的处理能力可以总体上作水平扩展，而不只仅是对某个节点作绝对的性能优化，由于流量的提高是很难准确预计的。

系统的可伸缩和低成本

系统的业务量在不一样的时间点，有高峰有低谷，好比餐饮行业有午高峰和晚高峰，还有电商的大促场景。咱们的架构设计要保证系统在业务高峰时，要能快速地增长资源来提高系统处理能力；反之，当业务低谷时，能够快速地减小系统资源，保证系统的低成本。

高可用、高性能、可伸缩和低成本，这些技术架构的目标不是孤立的，相互之间有关联，好比说有大流量请求进来，若是系统有很好的伸缩能力，它就能经过水平扩展的方式，保证系统有高性能，同时也实现了系统的高可用。若是系统的处理能力没法快速提高，没法保证高性能，那咱们仍是能够经过限流、降级等措施，保证核心系统的高可用。

我在前面也提到，这些目标不少时候会冲突，或者只能部分实现，咱们在作技术架构设计时，不能不顾一切地要求达到全部目标，而是要根据业务特色，选择最关键的目标予以实现。

好比说，一个新闻阅读系统，它和订单、钱没有关系，即便短期不可用，对用户影响也不大。但在出现热点新闻时，系统要能支持高并发的用户请求。所以，这里的设计，主要是考虑知足高性能，而不用太过于追求 4 个 9 或 5 个 9 的可用性。