目录
前言
1. 微服务架构到底是什么
1.1 软件架构的4+1视图
1.2 应用程序的两个层面需求
1.3 分层式架构风格
1.4 关于架构风格的六边形
1.5 什么是服务
1.6 微服务架构的架构风格
2 为应用程序定义微服务架构
2.1 定义应用程序架构的三步式流程
2.2 第一步：识别系统操作2.2.1 识别系统操作的步骤与一些事项：
2.3 第二步：定义服务
2.3.1 根据业务能力进行服务拆分
2.3.2 根据子域进行服务拆分
2.3.3 拆分的指导原则
2.3.4 拆分单体应用为服务的难点
2.3.5 上帝类阻碍了拆分
2.4 第三步：定义服务API2.4.1 定义服务API的步骤与事项
3. 本章小结
最后
这是一本关于微服务架构设计方面的书，这是本人阅读的学习笔记。首先对一些符号做些说明：
（）为补充，一般是书本里的内容；
[]符号为笔者笔注；
功能性需求；
非功能性需求，又称质量属性需求。（包括可扩展性、可靠性、可维护性、可测试性与可部署性等）[这点是架构为什么重要的原因]
流行的三层架构是应用于逻辑视图的分层架构，如下：
表现层：包含实现用户界面或外部API的代码；
业务逻辑层：包含业务逻辑；
数据持久层：实现与数据库交互的逻辑；
其弊端是：
单个表现层：无法展现应用程序可能不仅仅由单个系统调用的事实；
单一数据持久化层：无法展示应用程序可能与多个数据库进行交互的事实；
将业务逻辑层定义为依赖于数据持久化层：理论上，这样是依赖会妨碍在没有数据库的情况下测试业务逻辑；
六边形架构是分层架构风格的替代品 [解决分层架构的弊端]，六边形架构选择以业务逻辑为中心的方式组织逻辑视图。
图解：
业务逻辑具有一个或多个端口，端口定义了一组操作，关于业务逻辑如何与外部交互。
有两种端口：入站端口与出站端口；
入站端口是业务逻辑公开的API（如服务接口等，外部可以访问）；
出站端口是业务逻辑调用外部系统的方式（如储存库接口，定义数据访问操作的集合）；
业务逻辑周围是适配器，有两种适配器：入站适配器与出站适配器；
入站适配器：通过调用入站端口处理外部请求（如Spring MVC Controller，实现REST接口或一组Web界面）；
出站适配器：通过调用外部应用程序或服务处理来自业务逻辑的请求（如实现数据访问对象DAO类）；
好处：
将业务逻辑与适配器中包含的表示层和数据访问层的逻辑分离开，使单独测试业务逻辑容易；
反映现代应用程序的架构；
服务是一个单一的、可独立部署的软件组件，它实现了一些有用的功能。
服务具有API，为客户端提供对功能的访问；
API由命令、查询和事件组成；
开发人员无法绕过API直接访问服务内部的方法或数据（松耦合）；
它实现的视图由多个组件构成；
组件是服务，连接器是使这些服务能够协作的通信协议；
松耦合；
共享类库（里面实现不太可能改变的功能）；
服务大小不重要；
定义架构是一项艺术而非技术；在现实世界中，这是一个不断迭代和持续创新的过程。
第一步：识别系统操作；
第二步：定义服务；
第三步：定义服务API；
抽象的领域模型与系统操作能够回答这个应用“做什么”这一问题，有助于推动应用程序的架构设计。
第一步：创建抽象领域模型；
可以通过分析用户故事和场景中频繁出现的名词，经过迭代分析为这个领域模型的一些类；
第二步：定义系统操作；
识别系统必须的各种请求， 通常有两种：
命令型：创建、更新或删除数据的系统操作；
查询型：查询和读取数据的系统操作；
系统操作的切入点在分析用户故事和场景中频繁出现的动词；
需要考虑命令规范（参数、返回值和领域模型类）与行为规范（前置条件、后置条件）；
拆分步骤：
首先要确定业务能力，通常指这个组织的业务是做什么，可以通过对组织的目标、结构和商业化流程分析得来；
确定了业务能力后，就可以为每个能力组定义服务，这是一个非常主观的判断；
下图为FTGO应用程序从能力到服务的映射：
又称：基于领域驱动设计分解应用程序的方法
一些概念：
领域模型：以解决具体问题的方式包含了一个领域的知识；
DDD通用语言：定义了当前领域相关团队的词汇表，其有两个重要概念：
子域：是领域的一部分，识别方式跟识别业务类似；
限界上下文：领域模型的边界，通常每一个限界上下文对应一个或一组服务；
通过DDD的方式定义子域；
把子域对应为每一个服务；
下图为FTGO应用程序从子域到服务的映射：
受启发于面型对象设计原则。
单一职责原则：定义的每一个类都应该只有一个职责；
闭包原则：如果出于某种原因，两个类的修改必须耦合先后发生，那么就应该把它们放在同一个包内；
网络延迟：
描述：对服务的特定分解导致两个服务之间的大量往返调用；
解决：把多个相关服务组合在一起，用编程语言的函数调用替换进程间通信；或者实施批处理API在一次往返中获取多个对象；
同步进程间通信导致可用性降低：
描述：使用REST协议同步调用其他服务时，会降低service的可用性；
解决：参考《第三章 异步消息》；
在服务之间维护数据一致性：
描述：当一个系统操作需要修改多个服务的数据时，需要维护数据的一致性；
解决：参考《第四章 Saga相关》；
获取一致的数据视图：
描述：无法跨多个数据库获得真正一致的数据视图；
解决：（在实践中很少带来真正的问题）；
上帝类阻碍了拆分：
描述：上帝类是在整个应用程序中使用的全局类，通常与多个服务的状态与行为绑定；
解决：参考本章《2.3.5 上帝类阻碍了拆分》，以FTGO的Order类为例；
在定义微服务架构时，必须识别并消除上帝类。
问题描述：在FTGO应用程序中，Order类与订单处理、餐馆订单管理、送餐与付款等服务有关，具有复杂的状态模型，如下图所示；
解决方法：
将Order类打包到库中并创建一个中央Order数据库（违反松耦合原则）；
将Order数据库封装在Order Service中，该服务由其他服务调用用以检索和更新订单（问题在于Order Service将成为一个纯数据服务，成为很少或没有业务逻辑的贫血领域模型）；
【推荐】应用DDD将每个服务视为具有自己的领域模型的单独子域，使每个与订单有关的服务都有自己的领域模型及其对应的Order类版本，如下图所示；
第一步：把系统操作分配给服务；
即确定哪个服务是请求的初始入口点；
第二步：确定支持服务协作所需要的API；
某些系统操作完全由单个服务处理；也可能分散在多个服务周围。
架构决定了软件的各种非功能性因素，比如可维护性、可测试性、可部署性和可扩展性，它们会直接影响开发速度；
微服务架构是一种架构风格，它给应用程序带来了更高的可维护性、可测试性、可部署性和可扩展性；
微服务中的服务是根据业务需求进行组织的，按照业务能力或者子域，而不是技术上的考量；
有两种分解模式：
按业务能力分解，其起源于业务架构；
基于领域驱动设计的概念，通过子域进行分解；
可以通过应用DDD并为每个服务定义单独的领域模型来消除上帝类，正是上帝类引起了阻碍分解的交织依赖项。
新人制作，如有错误，欢迎指出，感激不尽！
欢迎关注公众号，会分享一些更日常的东西！
如需转载，请标注出处！