互联网技术架构演变之路
单体架构
概念
- 单体架构（也叫单一应用架构）就是将应用程序的所有功能都打包成一个独立的单元。当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署和维护成本。
特点
- 所有的功能集成在一个项目工程中。
- 所有的功能打一个 War 包部署到服务器。
- 应用与数据库分开部署。
- 通过部署应用集群和数据库集群来提高系统的性能。
优点
- 开发简单：一个 IDE 就可以快速构建单体应用。
- 便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享。
- 易于测试：单体应用一旦部署，所有的服务或特性就都可以使用，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始。
- 容易部署：整个项目就一个 War 包，Tomcat 安装好之后，直接运行项目就可以。集群化部署也很容易，部署多个 Tomcat 和一个 Nginx 就可以搞定。
缺点
- 阻碍持续交付：随着时间的推移，单体应用可能会变得比较大，构建和部署时间也相应地延长，不利于频繁部署，妨碍持续交付。
- 不够灵活：随着项目逐渐变大，整个开发流程的时间也会变得很长，即使在仅仅更改了一行代码的情况下，开发人员需要花费几十分钟，甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。如果多个开发人员共同开发一个应用程序，那么还要等待其他开发人员完成了各自的开发，这大大降低了团队的灵活性和功能交付频率。
- 受技术栈限制：项目变得越来越大的同时，应用所使用的技术也会变得越来越多。这些技术有些是不兼容的，就比如在一个项目中大范围地混合使用 Java 和 C++ 几乎是不可能的事情。在这种情况下，就需要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能。
- 可靠性差：当某个模块出现了问题，导致内存溢出，最后会影响到整个项目的正常运行。
- 伸缩性差：系统的扩容只能针对应用进行扩容，不能做到对某个功能进行扩容，扩容后必然带来资源浪费的问题。
- 技术债务：假设代码库中有一个混乱的模块。此时，需要添加一个新功能，如果这个模块的结构清晰，可能只需要 2 天时间就可以添加好新功能，但是如今这个模块的结构很混乱，可能需要 4 天时间，多出来的这两天就是债务利息。随着时间推移、人员变动，技术债务必然也会随之增多。
关键点
- 数据访问层（ORM 框架）
垂直架构
概念
- 垂直架构（也叫垂直应用架构）是指将单体架构中的多个模块拆分为多个独立的应用，最终形成多个独立的单体架构，如图所示。
特点
- 以单体架构规模的项目为单位进行垂直划分，也就是将一个大项目拆分成多个单体架构项目。
- 项目与项目之间存在代码冗余，耦合性较大，比如上图中三个项目都存在用户模块。
优点
- 开发成本低，架构简单。
- 避免单体应用的无限扩大。
- 系统拆分实现了流量分担，解决了并发问题。
- 可以针对不同系统进行扩容、优化。
- 方便水平扩展，负载均衡，容错率提高。
- 不同的项目可以采用不同的技术。
- 系统间相互独立。
缺点
- 每个应用都包含了 MVC 三层的所有代码。
- 垂直架构中相同逻辑代码需要不断地复制，不能复用。
- 系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。
- 各个应用之间不可能完全独立，大量应用之间需要相互交互，调用关系相对复杂。
- 系统之间相互调用，如果某个系统的端口或者 IP 地址发生改变，调用系统需要手动变更。
- 不适用页面经常修改的场景，如果单个应用对应的页面修改了，需要重新部署该应用的所有代码到服务器。
关键点
- 用于加速前端页面开发的 Web 框架（MVC）
分布式架构
- 概念
- 分布式架构是指在垂直架构的基础上，将公共业务模块抽取出来，作为独立的服务供其他调用者消费，以实现服务的共享和重用，如图所示。
- RPC：远程过程调用（Remote Procedure Call），业内有非常多的协议和技术都实现了 RPC 的过程，比如：HTTP RESTful 风格，Java RMI 规范、WebService SOAP 协议、Hession 等。
- 优点
- 垂直和横向扩展都比较容易
- 前端页面可以快速迭代开发
- 提高了系统整体的高可用、高性能、高并发方面的能力
- 缺点
- 系统的复杂性提高了很多，包括开发与运维方面
- 关键点
- 分布式服务框架（RPC）
- 如何提高业务的复用程度
- 如何拆分业务（业务边界是什么）
什么是服务治理
- 分布式架构中的服务越来越多，导致交互越发复杂，不可避免会出现资源浪费的情况。为了更好地管理复杂的调用关系、提高资源利用率，需要引入服务治理。服务治理一般包括以下内容：
- (1) 通过注册中心管理所有服务（即服务注册与发现）
- (2) 路由选择、负载均衡及容错处理
- (3) 服务升 / 降级，熔断，权重调整
- (4) 服务过滤（黑名单、白名单）
- (5) 服务状态检测、监测
- (6) 服务权限控制
- (7) 服务依赖关系
- (8) 监控与统计
- (9) 资源隔离
SOA 架构
概念
- 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心。当服务越来越多，容量的评估和小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
- SOA（Service-Oriented Architecture，面向服务的架构）是一个组件模型将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来，如图所示。
- ESB（Enterparise Servce Bus）企业服务总线，从软件设计的角度上来说，ESB 是一个抽象的间接层，提取了服务调用过程中调用与被调用动态交互中的一些共同的东西，减轻了服务调用者的负担。Java 编程思想里提到：所有的软件设计问题都可以通过增加一个抽象的间接层而得到解决或者得到简化。简单来说，ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。ESB 包含的功能包括：负载均衡、流量控制、加密处理、服务监控、异常处理、监控告警等。
特点
- 基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的形式给各系统提供服务。
- 各项目（系统）与服务之间采用 WebService、RPC 等方式进行通信。
- 使用 ESB 企业服务总线作为项目与服务之间通信的桥梁。
优点
- 将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。
- 可以针对不同服务的特点制定集群及优化方案。
- 采用 ESB 来减少系统中的接口耦合。
缺点
- 系统与服务的界限模糊，不利于开发及维护。
- 虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
- 抽取的服务的粒度过大，系统与服务之间耦合性高。
- 涉及多种中间件，对开发人员技术栈要求高。
- 服务关系复杂，运维、测试部署困难。
微服务架构
。
概念
- 微服务架构是在 SOA 架构上做的升华，微服务架构强调的一个重点是 “业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用，这些小应用之间通过服务调用完成交互和集成。
- 微服务架构 = 80% 的 SOA 架构思想 + 100% 的组件化架构思想 + 80% 的领域建模思想。
特点
- 将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。
- 微服务中每一个服务都对应唯一的业务能力，遵循单一原则。
- 微服务之间采用 HTTP RESTful 等轻量协议传输。
优点
- 可扩展性：每个服务可以独立扩展，避免了单个系统瓶颈。
- 容错性：一个服务的故障不会影响到其他服务，提升了系统的可靠性。
- 技术独立性：不同的服务可以使用不同的技术栈，适应不同的业务需求。
- 团队独立性：不同团队可以独立开发、维护各自的服务，提高了开发效率。
- 独立部署：各个微服务可以独立部署，减少了因大规模更新而导致的系统停机。
- 数据库分离：每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
缺点
- 复杂性：服务数量增多后，系统的管理、监控和调试变得更加复杂。
- 网络开销：服务之间通过网络通信，可能带来延迟和带宽消耗。
- 数据一致性：分布式系统中的数据一致性难以保证，可能需要采用最终一致性模型。
- 部署挑战：尽管每个服务可以独立部署，但全系统的部署和协调工作变得更复杂。
- 网络开销：微服务将原来的函数式调用改为服务调用，不管是用 RPC，还是 HTTP RESTful 方式，都可能带来延迟和带宽消耗。这是再所难免的，往往需要将原来的串行编程改为并发编程甚至是异步编程，增加了技术门槛。
- 开发成本：服务的划分、设计和维护增加了开发成本，尤其是初期阶段。分布式系统开发的技术成本高（网络问题、容错问题、调用关系、分布式事务等），对团队挑战大。
- 测试难度：服务之间是通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时候自动化测试就显得非常重要。如果靠人工一个个接口去测试，那工作量就太大了，所以 API 文档的管理尤为重要。
互联网项目的架构演进图
Dubbo 官方的架构演进图
提示
Dubbo 是 SOA 时代的产物，Spring Cloud 是微服务时代的产物。