1 深入理解微服务架构
1.1 对比SOA
1 服务粒度：整体上来说，SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。
2 服务通信：
SOA 采用了 ESB 作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现；
微服务推荐使用统一的协议和格式，例如，RESTful 协议、RPC 协议，无须 ESB 这样的重量级实现，且仅仅做消息传递，对消息格式和内容一无所知。3 服务交付：
SOA 对服务的交付并没有特殊要求，因为 SOA 更多考虑的是兼容已有的系统；
微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。4 应用场景：
SOA 更加适合于庞大、复杂、异构的企业级系统；
微服务更加适合于快速、轻量级、基于 Web 的互联网系统，这类系统业务变化快，需要快速尝试、快速交付。
SOA 和微服务本质上是两种不同的架构设计理念，只是在“服务”这个点上有交集而已
微服务并没有减少复杂度，而只是将复杂度从 ESB 转移到了基础设施
1.2 微服务的复杂性
1 如果服务划分过细，则服务间关系会很复杂
2 如果服务数量太多，团队的开发效率会急剧下降
3 如果调用链太长，导致性能下降、问题定位困难
4 如果没有自动化支撑，则无法快速交付
5 如果没有服务治理（服务路由、服务故障隔离、服务注册和发现等，需要依赖自动化的服务管理系统），微服务数量多了后管理混乱
1.3 最佳实践-方法
1.3.1 如何把握拆分粒度（服务粒度）
基于团队规模进行拆分：
微服务设计和开发阶段，一个微服务三个人负责开发；
维护阶段，平均 1 个人维护 1 个微服务甚至几个微服务都可以，考虑到人员备份问题，则每个微服务最好都安排 2 个人维护，每个人都可以维护多个微服务。
1.3.2 按照什么维度进行拆分（拆分方法）
- 1 基于业务逻辑拆分
根据团队规模划分业务模块的粒度
- 2 基于可扩展拆分
将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。
稳定的服务粒度可以粗一些，即使逻辑上没有强关联的服务，也可以放在同一个子系统中
不稳定的服务粒度可以细一些，但也不要太细，始终记住要控制服务的总数量。
- 3 基于可靠性拆分
将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，这样可以单独保证核心服务的高可用。
- 4 基于性能拆分
类似基于可靠性拆分，基于性能拆分将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。
- 综合
以上几种拆分方式不是多选一，而是可以根据实际情况自由排列组合
例如可以基于可靠性拆分出服务 A，基于性能拆分出服务 B，基于可扩展拆分出 C/D/F 三个服务，加上原有的服务 X，最后总共拆分出 6 个服务（A/B/C/D/F/X）。
1.3.3 需要什么基础设施支撑（基础设施）
实现automated：
“服务发现”“服务路由”等其实都是 ESB 的功能，只是在微服务中剥离出来成了独立的基础系统。
一般建议按照下面优先级来搭建基础设施：
-
服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
-
接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
-
自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
-
服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。
接下来解析11个基础设施的最佳实践
1.4 最佳实践-基础设施
1.4.1 自动化测试
自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测试，理想情况是每类测试都自动化，达到”快速交付”的目的
如果因为团队规模和人力的原因无法全面覆盖，至少要做到接口测试自动化
1.4.2 自动化部署
自动化部署系统包括版本管理、资源管理（例如，机器管理、虚拟机管理）、部署操作、回退操作等功能。
1.4.3 配置中心
配置中心包括配置版本管理（例如，同样的微服务，有 10 个节点是给移动用户服务的，有 20 个节点给联通用户服务的，配置项都一样，配置值不一样）、增删改查配置、节点管理、配置同步、配置推送等功能。
1.4.4 接口框架
在实践过程中，需要统一接口协议(HTTP/REST)和接口传递(JSON)的数据格式。
接口框架不是一个可运行的系统，一般以库或者包的形式提供给所有微服务调用。
1.4.5 API 网关
内部的微服务之间是互联互通的，相互之间的访问都是点对点的，而外部系统只会关注它需要的能力，而不会关注这个能力应该由哪个微服务提供。
因此微服务需要一个统一的 API 网关，负责外部系统的访问操作，主要包括接入鉴权（是否允许接入）、权限控制（可以访问哪些功能）、传输加密、请求路由、流量控制等功能。
1.4.6 服务发现
使得节点的变化能够及时同步到所有其他依赖的微服务。
服务发现主要有两种实现方式：自理式和代理式。
自理式结构：每个微服务自己完成服务发现。
代理式结构：微服务之间有一个负载均衡系统（图中的 LOAD BALANCER 节点），由负载均衡系统来完成微服务之间的服务发现。
无论是哪种方式，服务发现的核心功能都是服务注册表；
注册表记录了所有的服务节点的配置和状态，每个微服务启动后都需要将自己的信息注册到服务注册表，然后由微服务本身或者 LOAD BALANCER 系统到服务注册表查询可用服务。
1.4.7 服务路由
有了服务发现后，微服务之间能够方便地获取相关配置信息，但具体进行某次调用请求时，我们还需要从所有符合条件的可用微服务节点中挑选出一个具体的节点发起请求，这就是服务路由需要完成的功能。
服务路由和服务发现紧密相关，服务路由一般不会设计成一个独立运行的系统，通常情况下是和服务发现放在一起实现的。
对于自理式服务发现，服务路由是微服务内部实现的；
对于代理式服务发现，服务路由是由 LOAD BALANCER 系统实现的。
无论放在哪里实现，服务路由核心的功能就是路由算法。
常见的路由算法有：随机路由、轮询路由、最小压力路由、最小连接数路由等。
1.4.8 服务容错
常见的服务容错包括请求重试、流控和服务隔离。
通常情况下，服务容错会集成在服务发现和服务路由系统中。
1.4.9 服务监控
服务监控的主要作用有：
- 实时搜集信息并进行分析，避免故障后再来分析，减少了处理时间。
- 服务监控可以在实时分析的基础上进行预警，在问题萌芽的阶段发觉并预警，降低了问题影响的范围和时间。
通常情况下，服务监控需要搜集并分析大量的数据，因此建议做成独立的系统，而不要集成到服务发现、API 网关等系统中。
1.4.10 服务跟踪
服务监控可以做到微服务节点级的监控和信息收集，但如果需要跟踪某一个请求在微服务中的完整路径，服务监控是难以实现的。因为如果每个服务的完整请求链信息都实时发送给服务监控系统，数据量会大到无法处理。
服务监控和服务跟踪的区别可以简单概括为宏观和微观的区别。
例如，A 服务通过 HTTP 协议请求 B 服务 10 次，B 通过 HTTP 返回 JSON 对象；
服务监控会记录请求次数、响应时间平均值、响应时间最高值、错误码分布这些信息；
服务跟踪会记录其中某次请求的发起时间、响应时间、响应错误码、请求参数、返回的 JSON 对象等信息。
1.4.11 服务安全
服务安全主要分为三部分：接入安全、数据安全、传输安全。
通常情况下，服务安全可以集成到配置中心系统中进行实现，即配置中心配置微服务的接入安全策略和数据安全策略，微服务节点从配置中心获取这些配置信息，然后在处理具体的微服务调用请求时根据安全策略进行处理。
由于这些策略是通用的，一般会把策略封装成通用的库提供给各个微服务调用。基本架构如下：
2 微内核架构详解
微内核架构（Microkernel Architecture），也被称为插件化架构（Plug-in Architecture），是一种面向功能进行拆分的可扩展性架构，通常用于实现基于产品（原文为 product-based，指存在多个版本、需要下载安装才能使用，与 web-based 相对应）的应用。
2.1 基本架构
微内核架构包含两类组件：核心系统（core system）和插件模块（plug-in modules）。
核心系统负责和具体业务功能无关的通用功能；
插件模块负责实现具体的业务逻辑。
微内核的架构本质就是将变化部分封装在插件里面，从而达到快速灵活扩展的目的，而又不影响整体系统的稳定。
2.2 设计关键点
1 插件管理：核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件
使用插件注册表机制使核心系统能获得插件的信息
2 插件连接：插件如何连接到核心系统
常见的连接机制有 OSGi（Eclipse 使用）、消息模式、依赖注入（Spring 使用）、RPC 或者 HTTP Web 的方式。
3 插件通信：插件间的通信
核心系统需要提供插件通信机制
和计算机类似，计算机的 CPU、硬盘、内存、网卡是独立设计的配件，但计算机运行过程中，CPU 和内存、内存和硬盘肯定是有通信的，计算机通过主板上的总线提供了这些组件之间的通信功能。
2.3 OSGI架构简析
逻辑架构图：模块层实现插件管理功能、生命周期层实现插件连接功能、服务层实现插件通信的功能
2.4 规则引擎架构简析
规则引擎从结构上来看也属于微内核架构的一种具体实现，其中执行引擎可以看作是微内核，执行引擎解析配置好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵活多变。
基本架构：
- 插件管理
规则引擎中的规则就是微内核架构的插件，引擎就是微内核架构的内核。
规则可以被引擎加载和执行。规则引擎架构中，规则一般保存在规则库中，通常使用数据库来存储。
- 插件连接
规则引擎的插件连接实现机制是规则语言。
- 插件通信
规则引擎的规则之间进行通信的方式是数据流和事件流，由于单个规则并不需要依赖其他规则，因此规则之间没有主动的通信，规则只需要输出数据或者事件，由引擎将数据或者事件传递到下一个规则。