一、微服务架构概述【4】（微服务的设计原则）

╰+攻爆jí腚メ 2021-11-09 14:16 572阅读 0赞

### 微服务的设计原则 ###

![aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMjYzNjU0MC1kNmY5NTViYjY3NmNjMjBlLnBuZz9pbWFnZU1vZ3IyL2F1dG8tb3JpZW50L3N0cmlwJTdDaW1hZ2VWaWV3Mi8yL3cvMTAwMC9mb3JtYXQvd2VicA][]

**1、高内聚低耦合**

*  紧密关联的事物应该放在一起，每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情（每次只有一个更改它的理由)。如下图：有四个服务a,b,c,d，但是每个服务职责不单一，a可能在做b的事情，b又在做c的事情，c又同时在做a的事情，通过重新调整，将相关的事物放在一起后，可以减少不必要的服务。
 *  轻量级的通信方式
    
     *  同步RESTful（GET/PUT/POST...），基于http，能让服务间的通信变得标准化并且无状态，关于RESTful API的成熟度，可参`Richardson为REST定义的成熟度模型`
     *  异步（消息队列/发布订阅）
 *  避免在服务与服务之间共享数据库
    
     
    
    ![aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMjYzNjU0MC1mNGU1MjY1NTc2YWIyZWQwLnBuZz9pbWFnZU1vZ3IyL2F1dG8tb3JpZW50L3N0cmlwJTdDaW1hZ2VWaWV3Mi8yL3cvMTAwMC9mb3JtYXQvd2VicA][]

**2、高度自治**

*  独立部署运行和扩展
    
     *  每个服务能够独立被部署并运行在一个进程内
     *  这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
 *  独立开发和演进
    
     *  技术选型灵活，不受遗留系统技术栈的约束。
     *  合适的业务问题可以选择合适的技术栈，可以独立的演进
     *  服务与服务之间采取与语言无关的API进行集成
 *  独立的团队和自治
    
     *  团队对服务的整个生命周期负责，工作在独立的上下文中， 谁开发，谁维护。

**3、以业务为中心**

*  每个服务代表了特定的业务逻辑
 *  有明显的边界上下文
 *  围绕业务组织团队
 *  能快速的响应业务的变化
 *  隔离实现细节，让业务领域可以被重用

**4、弹性设计**

*  设计可容错的系统
    
     *  拥抱失败，为已知的错误而设计
     *  依赖的服务挂掉
     *  网络连接问题
 *  设计具有自我保护能力的系统
    
     *  服务隔离
     *  服务降级
     *  限制使用资源
     *  防止级联错误

Netfilix 提供了一个比较好的解决方案，具体的应对措施包括：网络超时/限制请求的次数/断路器模式/提供回滚等。

**5、日志与监控**

当产品环境出错时，需要快速的定位问题，检测可能发生的意外和故障。而日志与监控是快速定位和预防的不二选择，在微服务架构中更是至关重要。

*  高度可观察，我们需要对正在发生的事情有一个整体的视角。
 *  聚合你的日志，聚合你的数据，从而当你遇到问题时，可以深入分析原因。
 *  当需要重现令人讨厌的问题，或仅仅查看你的系统在生产环境如何交互时，`关联标识`可以帮助你跟踪系统间的调用。

监控主要包括服务可用状态、请求流量、调用链、错误计数，结构化的日志、服务依赖关系可视化等内容，以便发现问题及时修复，实时调整系统负载，必要时进行服务降级，过载保护等等，从而让系统和环境提供高效高质量的服务。

比如商业解决方案`splunk，sumologic`，以及开源产品ELK他们都可以用于日志的收集，聚合，展现，并提供搜索功能，基于一定条件，触发邮件警告。

`Spring boot admin`也可以用于服务可用性的监控， `hystrix`除了提供熔断器机制外，它还收集了一些请求的基本信息（比如请求响应时间，访问计算，错误统计等），并提供现成的dashboard将信息可视化。

关于性能监控和调用链追踪，考虑使用dynatrace和zipkin/Sleuth

**6、自动化**

在微服务架构下，面临如下挑战：

*  分布式系统
 *  多服务，多实例
 *  手动测试，部署，发布太消耗时间
 *  反馈周期太长

传统的手工运维方式必然要被淘汰，微服务的实施是有一定的先决条件：那就是自动化，当服务规模化后需要更多`自动化`和`标准化`的手段来提升效能和降低成本。

*  自动化测试必不可少，因为对比单块系统，确保我们大量的服务正常工作是一个更复杂的过程。
 *  调用一个统一的命令行，以相同的方式把系统部署到各个环境。
 *  考虑使用环境定义来帮助你明确不同环境间的差异，但同时保持使用统一的方式进行部署的能力。
 *  考虑创建自定义镜像来加快部署，并且拥抱全自动化创建不可变服务器的实践。

`自动化一切可以自动化的`，降低部署和发布的难度, 比如： 在持续集成和持续交付中，自动化编译，测试，安全扫描，打包，集成测试，部署，随着服务越来越多，在发布过程中，需要进一步自动化蓝绿部署（做到老版本到新版本的平滑过渡）还可以使用pipeline as code的实践，用代码来描述你的流水线。关于部署有很多选择，可以使用虚拟机，容器docker，或者流行的无服务架构lambda（AWS Lambda 也有一些明显的局限。它并不适合被用来部署长期运行的服务，请求需要在 300 秒内完成，当然你可以通过hack的方式延迟时间)。

然后， 可以采用基础设施及代码的实践，比如亚马逊的`cloudformation`，还有`terrform`，通过代码来描述计算和网络等基础设施， 可以快速为一个全新的服务，构架它所需要的环境，保持各`环境的一致性`。

[aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMjYzNjU0MC1kNmY5NTViYjY3NmNjMjBlLnBuZz9pbWFnZU1vZ3IyL2F1dG8tb3JpZW50L3N0cmlwJTdDaW1hZ2VWaWV3Mi8yL3cvMTAwMC9mb3JtYXQvd2VicA]: /images/20211109/c1a985339f3c4303bab31bf30b2413eb.png
[aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMjYzNjU0MC1mNGU1MjY1NTc2YWIyZWQwLnBuZz9pbWFnZU1vZ3IyL2F1dG8tb3JpZW50L3N0cmlwJTdDaW1hZ2VWaWV3Mi8yL3cvMTAwMC9mb3JtYXQvd2VicA]: /images/20211109/0ff68bbad307414aa2684dc0c58d2ea8.png