本系列笔记来自于《微服务实战》，重要的地方进行了留存笔记，方便学习和阅览。

题目和案例，会结合一些自身情况进行调整，以便更好的阅读和理解。

第一部分、概述

第一章、微服务的设计与运行

1.1、什么是微服务应用

内聚度：用来衡量某个模块中的各个元素属于一个整体的紧密程度的指标。

耦合度：衡量一个元素对另一个元素的内部运行逻辑的了解程度的指标。

将那些因相同原因而修改的内容聚合到一起，将那些因不同原因而修改的内容进行拆分。

微服务的 5 个特性：

• 每个微服务只负责一个功能。这个功能可能是业务相关的功能，也可能是共用的技术功能。

• 每个微服务都拥有自己的数据存储

• 微服务自己负责编排和协作（控制消息和操作的执行顺序来完成某些有用的功能）

• 微服务可以独立部署

• 每个微服务都是可代替的

1.1.1、通过分解来实现扩展

《可扩展性的艺术》书中提出的一种三维扩展方案。

1.1.2、核心原则

微服务开发的五大文化和架构原则：自治性、可恢复性、透明性、自动化和一致性

1、自治性

• 松耦合

• 可独立部署（服务按照定义好的契约来通信以实现松耦合，契约隐藏了实现的细节）

自治性也是一种团队文化。将各个服务的责任和所有权委派给有责任交付商业价值的团队。

2、可恢复性

微服务需要具备故障隔离机制

3、透明性

应用中的每个服务都会产生来自业务、运营和基础设施的数据，应用日志以及请求记录。当故障发生的时候，开发者需要记得微服务是可观测和诊断的。

4、自动化

1）DevOps 技术-》基础设施即代码技术。

2）完全通过 API 进行编程的基础设施环境。

5、一致性

SOA 面向横向拆分服务，而微服务偏向于纵向拆分服务。每个服务应该与一个独立的业务功能相匹配。

1.1.3、微服务的现状问题

压力描述规模系统的处理规模可能大大超过了最初的技术选型的承载能力新功能新的功能可能和现有的功能关系并不紧密，或者换一种技术可能更容易解决问题工程团队的壮大随着团队越来越大，需要沟通的人和渠道也增多，新加入的开发要花更多的时间来理解现有的系统，相应的创造产品价值的时间也就少了技术债务系统所增加的复杂度（包括之前的开发决策导致的债务）导致修改的难度提高国际分发数据一致性，可用性和延迟性面临巨大挑战

如果上述的内容能够作为收益，那么就可以使用微服务。

1.1.4、微服务的可预测收益

1、技术差异性

2、开发冲突

• 变更周期耦合，导致协作障碍并增大回滚的风险

• 没有严格规范团队，软件模块和上下文边界含混不清，导致组件之间产生意料之外的紧耦合

• 应用的大小成为痛点：持续集成作业，系统发布（甚至是本地应用启动）都会越来越慢

3、微服务降低冲突和风险

那么你是否需要微服务系统架构呢？也就是服务化改造？答案是结合你当前的收益和现状来评估，如果收益可观，那么建议你逐步从单体应用架构迁移到微服务系统架构中，因为从系统和业务结合的角度来说，改造成本越低，那么影响越小。

1.2、微服务的挑战

• 识别和划定微服务范围需要大量专业的业务领域知识

• 正确识别服务间的边界和契约

• 微服务是分布式系统，所以需要对状态，一致性和网络可靠性这些内容做出不同假设

• 跨网络分发系统组件以及不断增长的技术差异性，会导致微服务出现新的故障形式

• 难以了解和验证正常运行过程中会发生什么事情

微服务方案推荐在系统设计中采用演进式的方案，这样开发者可以在不修改现有服务的情况下独立开发新的功能，就能将变更的风险和代价最小化。

微服务降低了开发的冲突，但是增加了运维阶段系统部署、验证以及监控的复杂度。

1.3、微服务开发周期

1.3.1、微服务设计的考虑因素

• 是从一个单体应用起步，还是一开始就使用微服务

• 应用的整体架构以及开放给外部消费者的接口

• 如何识别和划定服务的边界

• 服务之间是如何通信的？同步还是异步？

• 如何实现服务的可恢复性

1.3.2、微服务部署

• 微服务部署的人为操作标准化（通过容器 docker 来在运行环境层面和技术角度完成服务自治）

• 实现持续交付流水线

开发者应该关注的 2 个点：

• 制订一组软件必须通过的验证条件。在部署流程的每个环节，开发者都应该能够证明代码的正确性。

• 代码从提交状态发布到生产环境上的流水线实现自动化。

1.3.3、服务监控

• 发现薄弱的环节并进行重构

• 了解各个服务的行为并通过收集日志和一些数据指标，统一起来用于分析和告警。

PS：

采用微服务的团队需要在运维方面比较成熟，并且关注于服务的整个生命周期，而不是只关注设计和开发阶段。

举个例子：上述图为功能模型总览，也就是总览类型的领域模型。也可以小到一个系统的拆分不同功能的堆积模块，比如如下图

防止构建贫血服务：只是执行琐碎的增删改查操作。

第二章、实际案例引导

• 了解当前系统的现状，明确痛点（调查研究，原型设计，与客户同事或者其他终端用户进行访谈）

• 领域建模识别微服务（梳理业务流程，明确交付的价值是什么？判断哪些功能关系紧密，并放在一起作为单独部署的服务）领域系统设计可以参考之前的文章：https://xie.infoq.cn/article/ad6eef21ac5d7ec1cdb5f5135
  

巴士系数：用来衡量由团队成员之间的知识未被分享所造成的风险大小的指标，源自于以防他们被巴士撞了。巴士系数越低，团队的风险越大。（形容团队中有多少人同时消失开发者的项目就注定失败了）