从0开始学架构4 - 可扩展篇

￡神魔★判官ぃ 2022-04-24 04:02 195阅读 0赞

## 从0开始学架构.可扩展篇 ##

--------------------

### 32 | 可扩展架构的基本思想和模式 ###

今天我们进入架构可扩展模式的学习，这部分内容包括分层架构、SOA 架构、微服务和微内核等，先来聊聊架构的可扩展模式。

> 可扩展的基本思想

幸运的是，可扩展性架构的设计方法很多，但万变不离其宗，所有的可扩展性架构设计，背后的基本思想都可以总结为一个字：**拆**！

按照不同的思路来拆分软件系统，就会得到不同的架构。常见的拆分思路有如下三种。

*  面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。
 *  面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。
 *  面向功能拆分：将系统提供的功能拆分，每个功能作为一部分。

> 我再以一个简单的学生信息管理系统为例（几乎每个技术人员读书时都做过这样一个系统），拆分方式是：

*  面向流程拆分

展示层 → 业务层 → 数据层 → 存储层

最终的架构如下：

![d41940b54a682c27a4a67732d802e2d0.png][]

*  面向服务拆分

将系统拆分为注册、登录、信息管理、安全设置等服务，最终架构示意图如下：

![2944fd62f2a85467a07039acdc4b36f8.png][]

*  面向功能拆分

最终架构图如下：

![ee95fa950e123e86fdad63862d54894e.png][]

> 可扩展方式

不同的拆分方式，将得到不同的系统架构，典型的可扩展系统架构有：

*  面向流程拆分：分层架构。
 *  面向服务拆分：SOA、微服务。
 *  面向功能拆分：微内核架构。

--------------------

### 33 | 传统的可扩展架构模式：分层架构和SOA ###

> 分层架构

分层架构是很常见的架构模式，它也叫 N 层架构，通常情况下，N 至少是 2 层。例如，C/S 架构、B/S 架构。常见的是 3 层架构（例如，MVC、MVP 架构）、4 层架构，5 层架构的比较少见，一般是比较复杂的系统才会达到或者超过 5 层，比如操作系统内核架构。

> C/S 架构、B/S 架构

划分的对象是整个业务系统，划分的维度是**用户交互**，即将和用户交互的部分独立为一层，支撑用户交互的后台作为另外一层。例如，下面是 C/S 架构结构图。

![4648b7ffd305afcc34d5f1414f8298f2.png][]

> MVC 架构、MVP 架构

划分的对象是单个业务子系统，划分的维度是**职责**，将不同的职责划分到独立层，但各层的依赖关系比较灵活。例如，MVC 架构中各层之间是两两交互的：

![380007d08617ff7b212dad52032d6d54.png][]

> 逻辑分层架构

划分的对象可以是单个业务子系统，也可以是整个业务系统，划分的维度也是**职责**。虽然都是基于职责划分，但逻辑分层架构和 MVC 架构、MVP 架构的不同点在于，**逻辑分层架构中的层是自顶向下依赖的**。典型的有操作系统内核架构、TCP/IP 架构。例如，下面是 Android 操作系统架构图。

![28a0789dc7b125fffa36cb1524ff28eb.png][]

典型的 J2EE 系统架构也是逻辑分层架构，架构图如下：

![f696be773849a8a1bd6cd6c6ed86587a.png][]

针对整个业务系统进行逻辑分层的架构图如下：

![bc3978127300373b919b282e9f37c94a.png][]

无论采取何种分层维度，分层架构设计最**核心**的一点就是**需要保证各层之间的差异足够清晰，边界足够明显，让人看到架构图后就能看懂整个架构**，这也是分层不能分太多层的原因。

> 分层架构的特点

*  分层架构之所以能够较好地支撑系统扩展，本质在于**隔离关注点**（separation of concerns），即每个层中的组件只会处理本层的逻辑。
 *  分层时要保证层与层之间的依赖是稳定的，才能真正支撑快速扩展。
 *  分层结构的另外一个特点就是层层传递，也就是说一旦分层确定，整个业务流程是按照层进行依次传递的，不能在层之间进行跳跃。分层结构的这种约束，好处在于强制将分层依赖限定为两两依赖，降低了整体系统复杂度。

> 分层架构的缺点

分层架构另外一个典型的缺点就是**性能**，因为每一次业务请求都需要穿越所有的架构分层，有一些事情是多余的，多少都会有一些性能的浪费。当然，这里所谓的性能缺点只是理论上的分析，实际上分层带来的性能损失，如果放到 20 世纪 80 年代，可能很明显；但到了现在，硬件和网络的性能有了质的飞越，其实分层模式理论上的这点性能损失，在实际应用中，绝大部分场景下都可以忽略不计。

> SOA

SOA 的全称是 Service Oriented Architecture，中文翻译为“面向服务的架构”。

为了应对传统 IT 系统存在的问题，SOA 提出了 3 个关键概念。

*  服务。所有业务功能都是一项服务，服务就意味着要对外提供开放的能力，当其他系统需要使用这项功能时，无须定制化开发。
 *  ESB。ESB 的全称是 Enterprise Service Bus，中文翻译为“企业服务总线”。从名字就可以看出，ESB 参考了计算机总线的概念。计算机中的总线将各个不同的设备连接在一起，ESB 将企业中各个不同的服务连接在一起。因为各个独立的服务是异构的，如果没有统一的标准，则各个异构系统对外提供的接口是各式各样的。SOA 使用 ESB 来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。
 *  松耦合。松耦合的目的是减少各个服务间的依赖和互相影响。因为采用 SOA 架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖。如果做不到松耦合，某个服务一升级，依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。

SOA 解决了传统 IT 系统重复建设和扩展效率低的问题，但其本身也引入了更多的复杂性。SOA 最广为人诟病的就是 ESB，ESB 需要实现与各种系统间的协议转换、数据转换、透明的动态路由等功能。

> 为什么互联网企业很少采用 SOA 架构？

SOA是把多个系统整合，而微服务是把单个系统拆开来，方向正好相反

--------------------

### 34 | 深入理解微服务架构：银弹 or 焦油坑？ ###

> 微服务与 SOA 的关系

![affc409d5f4b05616e944001ebae0ba8.png][]

SOA 和微服务本质上是两种不同的架构设计理念，只是在“服务”这个点上有交集而已，因此两者的关系应该是上面第三种观点

![21db88f92cdcdf4826e837c0d8173b88.png][]

> 微服务的陷阱

我们看一下微服务具体有哪些坑：

*  服务划分过细，服务间关系复杂
 *  服务数量太多，团队效率急剧下降
 *  调用链太长，性能下降
 *  调用链太长，问题定位困难
 *  没有自动化支撑，无法快速交付
 *  没有服务治理，微服务数量多了后管理混乱

--------------------

### 35 | 微服务架构最佳实践 - 方法篇 ###

专栏上一期，我谈了实施微服务需要避免踩的陷阱，简单提炼为：

*  微服务拆分过细，过分强调“small”。
 *  微服务基础设施不健全，忽略了“automated”。
 *  微服务并不轻量级，规模大了后，“lightweight”不再适应。

> 服务粒度

针对微服务拆分过细导致的问题，我建议基于团队规模进行拆分，类似贝索斯在定义团队规模时提出的“两个披萨”理论（每个团队的人数不能多到两张披萨都不够吃的地步），分享一个我认为微服务拆分粒度的“三个火枪手”原则，即一个微服务三个人负责开发。

“三个火枪手”的原则主要应用于微服务设计和开发阶段，如果微服务经过一段时间发展后已经比较稳定，处于维护期了，无须太多的开发，那么平均 1 个人维护 1 个微服务甚至几个微服务都可以。当然考虑到人员备份问题，每个微服务最好都安排 2 个人维护，每个人都可以维护多个微服务。

> 拆分方法

*  基于业务逻辑拆分

这是最常见的一种拆分方式，将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。

*  基于可扩展拆分

将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为**稳定服务**，将经常变化和迭代的服务拆分为**变动服务**。稳定的服务粒度可以粗一些，即使逻辑上没有强关联的服务，也可以放在同一个子系统中，例如将“日志服务”和“升级服务”放在同一个子系统中；不稳定的服务粒度可以细一些，但也不要太细，始终记住要控制服务的总数量。

*  基于可靠性拆分

将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。具体拆分的时候，核心服务可以是一个也可以是多个，只要最终的服务数量满足“三个火枪手”的原则就可以。

*  基于性能拆分

基于性能拆分和基于可靠性拆分类似，将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。常见的拆分方式和具体的性能瓶颈有关，可以拆分 Web 服务、数据库、缓存等。例如电商的抢购，性能压力最大的是入口的排队功能，可以将排队功能独立为一个服务。

以上几种拆分方式不是多选一，而是可以**根据实际情况自由排列组合**，例如可以基于可靠性拆分出服务 A，基于性能拆分出服务 B，基于可扩展拆分出 C/D/F 三个服务，加上原有的服务 X，最后总共拆分出 6 个服务（A/B/C/D/F/X）。

> 基础设施

微服务基础设施如下图所示：

![f866d73aa62748074b6ddcfc1cee92c1.png][]

虽然建设完善的微服务基础设施是一项庞大的工程，但也不用太过灰心，认为自己团队小或者公司规模不大就不能实施微服务了。第一个原因是已经有开源的微服务基础设施全家桶了，例如大名鼎鼎的 Spring Cloud 项目，涵盖了服务发现、服务路由、网关、配置中心等功能；第二个原因是如果微服务的数量并不是很多的话，并不是每个基础设施都是必须的。通常情况下，我建议按照下面优先级来搭建基础设施：

1.  服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
2.  接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
3.  自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
4.  服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。

以上 3 和 4 两类基础设施，其重要性会随着微服务节点数量增加而越来越重要，但在微服务节点数量较少的时候，可以通过人工的方式支撑，虽然效率不高，但也基本能够顶住。

--------------------

### 36 | 微服务架构最佳实践 - 基础设施篇 ###

*  自动化测试
 *  自动化部署
 *  配置中心
 *  接口框架
 *  API 网关
 *  服务发现。服务发现主要有两种实现方式：自理式和代理式。
 *  服务路由
 *  服务容错
 *  服务监控
 *  服务跟踪
 *  服务安全

--------------------

### 37 | 微内核架构详解 ###

> 基本架构

微内核架构包含两类组件：核心系统（core system）和插件模块（plug-in modules）。核心系统负责和具体业务功能无关的通用功能，例如模块加载、模块间通信等；插件模块负责实现具体的业务逻辑，例如专栏前面经常提到的“学生信息管理”系统中的“手机号注册”功能。

微内核的基本架构示意图如下：

![a4b419cd879f821e457a18be288ec574.png][]

上面这张图中核心系统 Core System 功能比较稳定，不会因为业务功能扩展而不断修改，插件模块可以根据业务功能的需要不断地扩展。微内核的架构本质就是**将变化部分封装在插件里面，从而达到快速灵活扩展的目的，而又不影响整体系统的稳定**。

> 设计关键点

微内核的核心系统设计的关键技术有：插件管理、插件连接和插件通信。

> OSGi 架构简析

OSGi 的全称是 Open Services Gateway initiative，本身其实是指 OSGi Alliance。现在我们谈到 OSGi，如果没有特别说明，一般都是指 OSGi 的规范。

OSGi 框架的逻辑架构图如下：

![265e3265d64ee236a4d56eebd05a3882.png][]

> 规则引擎架构简析

规则引擎从结构上来看也属于微内核架构的一种具体实现，其中执行引擎可以看作是微内核，执行引擎解析配置好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵活多变。

例如电商促销，常见的促销规则，规则引擎却能够很灵活的应对这种需求，主要原因在于：

*  可扩展
 *  易理解
 *  高效率

[d41940b54a682c27a4a67732d802e2d0.png]: /images/20220220/d2eef9e1669d45dfae954e76b4c20430.png
[2944fd62f2a85467a07039acdc4b36f8.png]: /images/20220220/cb40fdcb4e9a42a29d3e6cd7b31fd0d5.png
[ee95fa950e123e86fdad63862d54894e.png]: /images/20220220/cccd506ddec546e999047edf9f124c82.png
[4648b7ffd305afcc34d5f1414f8298f2.png]: /images/20220220/bbb3619e6262460fa3f16c0882b4f4eb.png
[380007d08617ff7b212dad52032d6d54.png]: /images/20220220/074a967bd9e4475694b255867ae33936.png
[28a0789dc7b125fffa36cb1524ff28eb.png]: /images/20220220/bc9b2f8d299e42a48527a4a94a27ae5c.png
[f696be773849a8a1bd6cd6c6ed86587a.png]: /images/20220220/057630fd82ab493abad07f5c5e2747d5.png
[bc3978127300373b919b282e9f37c94a.png]: /images/20220220/2df9dbd19cc14753bcbc58ea0012cd70.png
[affc409d5f4b05616e944001ebae0ba8.png]: /images/20220220/3fedc25aeacf4102a1df97ee9bc365f4.png
[21db88f92cdcdf4826e837c0d8173b88.png]: /images/20220220/428c9fb11c0f464bb881c51518404dd4.png
[f866d73aa62748074b6ddcfc1cee92c1.png]: /images/20220220/54da04c9925d4368b9e01004455fd816.png
[a4b419cd879f821e457a18be288ec574.png]: /images/20220220/f787eb4d24d948bd9fc4f95303de482d.png
[265e3265d64ee236a4d56eebd05a3882.png]: /images/20220220/0a186243c6c9456db2a0898fac17a5a0.png