技术角 | 架构学习书摘总结（四）可扩展架构模式（下）

最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。

本文是该书第四部分下半部分，是书中第十四章、第十五章，主要介绍微服务、微内核架构等，涉及到微服务实践、OSGi架构等内容。

目录

▪第十四章 微服务

▪第十五章 微内核架构

▪其他相关摘要

第十四章 微服务

1. 微服务架构模式是一种将单个应用程序开发为一套小型服务的方法，每个小型服务都在自己的流程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务围绕业务功能构建，可通过全自动部署机制独立部署。
2. 微服务与SOA关系
   1. 服务粒度：SOA的服务粒度要粗一些，而微服务的服务粒度要细一些。
   2. 服务通信：微服务推荐使用统一的协议和格式，例如RESTful协议、RPC协议，无需ESB这样的重量级实现。而微服务的"dumb pipes"仅仅做消息传递，对消息格式和内容一无所知。
   3. 服务交付：微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。如果没有这些基础能力支撑，微服务规模一旦变大（例如超过20个微服务），整体就难以达到快速交付的要求，这也是很多企业在实行微服务时踩过的一个明显的坑，就是系统拆分为微服务后，部署的成本成指数上升。
   4. 应用场景：SOA更加适合于庞大、复杂、异构的企业级系统。微服务更加适合于快捷、轻量级、基于Web的互联网系统，这类系统业务变化很快，需要快速尝试、快速交付；同时基本都是基于Web，虽然开发技术可能差异很大（例如Java、C++、.NET等），但对外接口基本都是提供HTTP RESTful风格的接口，无需考虑在接口层进行类似SOA的ESB那样的处理。

总结表格如下：

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

1. 微服务的陷阱
   1. 服务划分过细，服务间关系复杂：服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度了。从理论的角度来计算，n个服务的复杂度是(n×(n−1))/2，整体系统的复杂度是随着微服务数量的增加呈指数级增加的。
   2. 服务数量太多，团队效率急剧下降：微服务的“微”字，本身就是一个陷阱，很多团队看到“微”字后，就想到必须将服务拆分得很细，有的团队人员规模的5-6人，然而却拆分出30多个微服务，平均每个人要维护5个以上的微服务。这样做给工作效率带来了明显的影响，一个简单的需求开发就需要涉及多个微服务。光是微服务之间的接口就有6-7个，无论设计、开发，还是测试、部署，都需要工程师不停地在不同的服务间切换。
   3. 调用链太长，性能下降
   4. 调用链太长，问题定位困难
   5. 没有自动化支撑，无法快速交付
   6. 没有服务治理，微服务数量多了后管理混乱

总结一下，微服务的陷阱主要有以下几点：

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

1. 微服务最佳实践
   1. 服务粒度：建议基于团队规模进行拆分。“三个火枪手”微服务拆分粒度原则，即一个微服务三个人负责开发。当我们在实施微服务架构时，根据团队规模来划分微服务数量，如果业务规模继续发展，团队规模扩大，我们再将已有的微服务进行拆分。 这样做的道理是：从系统规模来讲，3个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度；从团队管理来说，3个人可以形成一个稳定备份；从技术提升角度来说，3个人的技术小组既能够形成有效讨论，又能够快速达成一致意见。 “三个火枪手”的原则主要应用于微服务设计和开发阶段，如果微服务经过一段时间发展后已经比较稳定，处于维护期了，无须太多的开发，那么1个人维护1个微服务甚至几个微服务都可以。
   2. 拆分方法：
      1. 基于业务逻辑拆分：最常见拆分方式，将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。
      2. 基于可扩展拆分：将系统中的业务模块按照稳定性进行排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。这样的拆分主要是为了提升项目快速迭代的效率避免在开发的时候，不小心影响已有的成熟功能导致线上问题。
      3. 基于可靠性拆分：将系统中的业务模块按照优先级顺序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。这样拆分可以避免非核心业务故障影响核心服务、核心服务高可用方案可以更简单、能够降低高可用成本。
      4. 基于性能拆分：类似于基于可靠性拆分，将性能要求高或性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。

   以上几种拆分方式不是多选一，而是可以根据实际情况自由排列组合。

   1. 基础设施： 微服务并没有减少复杂度，而只是将复杂度从ESB转移到了基础设施。例如“服务发现”“服务路由”等其实都是ESB的功能，只是在微服务中剥离出来成了独立的基础系统。 每项微服务基础设施都是一个平台、一个系统、一个解决方案，如果要自己实现，其过程和做业务系统类似，都需要经过需求分析、架构设计、开发、测试、部署上线等步骤。
      1. 自动化测试 微服务将原本大一统的系统拆分为多个独立运行的“微”服务，微服务之间的接口数量大大增加，并且微服务提倡快速交付，版本周期短，版本更新频繁。因此必须通过自动化测试系统来完成绝大部分测试回归的工作。 自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测试，理想情况是每类测试都自动化。如果因为团队规模和人力的原因无法全面覆盖，至少要做到接口测试自动化。
      2. 自动化部署 相比大一统的系统，微服务需要部署的节点增加了几倍甚至几十倍，微服务部署的频率也会大幅提升，综合计算下来，微服务部署的次数是大一统系统部署次数的几十倍。这么大量的部署操作，如果继续采用人工手工处理，需要投入大量的人力，且容易出错，因此需要自动化部署的系统来完成部署操作。 自动化部署系统包括版本管理、资源管理（例机器管理、虚拟机管理）、部署操作、回退操作等功能。
      3. 配置中心 微服务需要一个统一的配置中心来管理所有微服务节点的配置。配置中心包括配置版本管理（例同样的微服务，有10个节点是给移动用户服务的，有20个节点给联通用户服务的，配置项都一样，配置值不一样）、增删改查配置、节点管理、配置同步、配置推送等功能。
      4. 接口框架 微服务提倡轻量级的通信方式，一般采用HTTP RESTful或RPC方式统一接口协议。但在实践过程中，光统一接口协议还不够，还需要统一接口传递的数据格式。例如，我们需要指定接口协议为HTTP RESTful，但我们还需要指定HTTP RESTful的数据格式采用JSON，并且JSON的数据都遵循一定规范。 同时，我们需要统一接口框架。接口框架不是一个可运行的系统，一般以库或包的形式提供给所有微服务调用。例如，针对上面的JSON样例，可以由某个基础技术团队提供多种不同语言的解析包(Java、Python、C等)。
      5. API网关 微服务需要一个统一的API网关，负责外部系统的访问操作。 API网关是外部系统访问的接口，所有的外部系统接入系统都需要通过API网关，主要包括接入鉴权（是否允许接入）、权限控制（可以访问哪些功能）、传输加密、请求路由、流量控制等功能。
      6. 服务发现 节点的变化能被即时同步到所有其他依赖的微服务。这就是服务的自动注册和发现。服务发现主要有自理式和代理式两种。 自理式结构就是指每个微服务自己完成服务发现。 代理式结构是指微服务之间有一个负载均衡系统，由负载均衡系统来完成微服务之间的服务发现。代理式的方式更清晰，微服务本身的实现也简单许多，但这个方案风险较大，第一是可用性风险，第二是性能风险，因此LOAD BALANCER系统需要设计成集群的模式，但LOAD BALANCER集群的实现本身又增加了复杂性。 不管是自理式还是代理式，服务发现的核心功能就是服务注册表，注册表记录了所有的服务节点的配置和状态，每个微服务启动后都需要将自己的信息注册到服务注册表，然后由微服务或LOAD BALANCER系统到服务注册表查询可用服务。
      7. 服务路由 服务路由和服务发现紧密相关，服务路由一般不会设计成一个独立运行的系统，通常情况下是和服务发现放在一起实现的。对于自理式服务发现，服务路由是微服务内部实现的；对于代理式服务发现，服务路由是由LOAD BALANCER系统实现的。常见的路由算法有：随机路由、轮询路由、最小压力路由、最小连接数路由等算法。
      8. 服务容错 需要微服务能够自动应对出错常见，及时进行处理。否则如果节点一鼓掌就需要人工处理，投入人力大，处理速度慢。而一旦处理速度慢，则故障就很快扩散。常见的服务容错包括请求充实、流控和服务隔离。 流控：通常情况下，流控由各个微服务节点自己实现，可以将流控策略包装成公共库提供给各个微服务使用，减少重复实现。 服务隔离：当某个微服务节点故障时，最快最简单的处理方式就是直接将当前故障节点下线隔离，避免故障进行扩散。通常情况下，服务隔离分为主动隔离、被动隔离和手动隔离。
      9. 服务监控 服务监控主要是有实时搜集信息并进行分析，避免故障后再来分析，减少了处理时间。服务监控可以在实时分析的基础上进行预警，在问题萌芽的阶段发觉并预警，降低了问题影响的范围和时间。
      10. 服务跟踪 即跟踪某一个请求在微服务中的完整路径。服务跟踪的关键技术有标注点、跟总数和span。 服务跟踪一般主要用于采样跟踪和染色跟踪。
      11. 服务安全 部分敏感数据或操作只能部分微服务可以访问，而不是所有的微服务都可以访问。因此需要设计服务安全机制来保证业务和数据的安全性。服务安全主要分为接入安全、数据安全、传输安全等部分。 服务安全可以集成到配置中心系统中进行实现，即配置中心配置微服务的接入安全策略和数据安全策略，微服务节点从配置中心获取这些配置信息，然后在处理具体的微服务调用请求时根据安全策略进行处理。由于这些策略是通用的，一般会把策略封装成通用的库提供给各个微服务调用。

第十五章 微内核架构

1. Microkernel Architecture，中文翻译为“微内核架构”，也被称为插件化架构(Plug-in Architecture)，是一种面向功能进行拆分的可扩展性架构，通常用于实现基于产品（英文原文为product-based，指存在多个版本、需要下载安装才能使用，与web-based相对应）的应用。 微内核架构包含两类组件：核心系统(core system)和插件模块(plug-in modules)。核心系统功能比较稳定，不会因为业务功能扩展而不断修改，插件模块可以根据业务功能的需要不断地扩展。微内核架构通过隔离变化到插件的方式提供了灵活性、可扩展性。
2. 微内核核心系统设计关键技术：
   1. 插件管理：核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。常见的实现方法是插件注册表机制。
   2. 插件连接：插件如何连接到核心系统。常见的连接机制有OSGi(Eclipse)、消息模式、依赖注入(Spring)、甚至使用分布式的协议都是可以的，比如RPC或HTTP Web的方式。
   3. 插件通信：指插件间的通信。由于插件之间没有直接联系，通信必须通过核心系统，因此核心系统需要提供插件通信机制。
3. OSGi架构
   1. 全称Open Services Gateway Initiative，本身其实是指OSGi Alliance。现在我们讨论OSGi，已经和嵌入式应用关联不大了，更多的是将OSGi当做一个微内核的架构模式。
   2. Eclipse采用的是OSGi框架称为Equinox，类似的实现还有Apache的Felix，Spring的Spring DM。
   3. 模块层(Module)：完成插件管理功能。
   4. 生命周期层(Lifecycle)：完成插件连接功能，提供了执行时模块管理、模块对底层OSGi框架的访问。
   5. 服务层(Service)：完成插件通信的功能。
4. 规则引擎架构
   1. 规则引擎从结构上来看也属于微内核架构的一种具体体现，其中执行引擎可以看做微内核，执行引擎解析配置好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵活多变。规则引擎在计费、保险、促销等业务领域应用较多。
   2. 规则引擎能够很灵活的应对促销方案规则组织组合之类的需求，主要是其可扩展、易理解、高效率。
   3. 目前最常用的规则引擎是开源的JBoss Drools，采用java编写，基于Rete算法。Drools具有以下优点：
      1. 非常活跃的社区支持以及广泛的应用；
      2. 快速的执行速度；
      3. 与Java Rule Engine API(JSR-94)兼容；
      4. 提供基于Web的BRMS——Guvnor。

其他相关摘要

1. OSGi中，插件被称为Bundle。