微服务是否适用于我的系统——《微服务架构设计模式》读书笔记

本文主要是《微服务架构设计模式》的摘抄笔记，对于想了解微服务架构是否适用于自己系统的朋友，可以一看：

 

一、写在最前面

第一、编写简洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。

第二、关注微服务的本质，即服务的分解和定义，而不是技术，如容器和其他工具。

第三、确保你的服务松耦合，并且何以独立开发、测试和部署，不要搞成分布式单体，那将会是巨大的灾难。

第四、不能只是在技术上采用微服务架构。拥抱DevOps的原则和实践，在组织结构上实现跨职能的自治团队，这必不可少。

 

 

 

二、你是否也遇到如下问题（单体地狱）

1. 被抱怨无法按时交付：业务人员总是抱怨为何研发团队要一次次错过产品的关键交付期限，即使技术团队已经使用了模块化开发、敏捷开发。

2. 一直纠结维持现状还是重构改变：如何同时解决眼前的各种项目需求问题和系统性地采纳微服务架构。

3. 现有系统已成为“泥球模式”：随意架构的、庞大的、草率的、布满了胶带和线路，如同意大利面条一般的代码丛林。

4. 过度的复杂性让后继开发者为难：因为“泥球模式”下的长期任性发展，系统本身过于庞大和复杂，以至于任何一个开发者都很难理解它的全部。因此，修复软件中的问题和正确地实现新功能就变得困难且耗时，各种交付截止时间都可能被错过。并且，由于代码库太难于理解，因此开发人员在更改时更容易出错，每一次更改都会让代码库变得更复杂、更难懂。

5. 开发速度缓慢：巨大的项目会把IDE工具搞慢、构建一次系统需要很长时间、每次启动也需要很长时间、测试更需要很长时间（因代码库的复杂性和唯一性，导致任何一个小改动，都需要全量回归测试）、把代码更改部署到生产环境的时间变得更长。因此，从编辑到构建、运行再到测试这个周期花费的时间越来越长，这严重地影响了团队的工作效率。

6. 敏捷实践不完整：众多开发人员都向同一个代码库提交代码更改，这常常使得这个代码库的构建结果处于无法交付的状态。当团队尝试采用功能分支来解决这个问题时，带来的是漫长且痛苦的合并过程。

7. 难以扩展：在对应用进行横向扩展时也遇到挑战，因为不同模块对资源的需求时相互冲突的。

8. 生产系统缺乏可靠性：因无法进行全面彻底的测试，且系统缺乏故障隔离（因为所有模块都在同一个进程中运行）,导致一出问题所有实例都受影响。

9. 长期依赖某个可能已经过时的技术栈：团队必须长期使用一套相同的技术栈，即使这个技术栈正在被废弃或者过时，在单体应用上采用新技术或者尝试新技术都是极其昂贵和高风险的，因为这个应用必须被彻底重写。

 

 

 

三、微服务架构的基本特点，以及应该在什么情况下使用微服务架构

软件架构其实对功能性需求影响并不大，架构的重要性在于它影响了应用的非功能性需求，也称为质量属性。随着“泥球模式”下系统的增长，各种质量属性和问题都浮出水面，最显著的就是影响软件交付速度的可维护性、可扩展性和可测试性。

专业过硬的团队可以减缓项目陷入单体地狱的速度，比如努力维护模块化应用、编写自动化测试等。但是，依然无法避免单体应用协同工作的问题、也无法解决日益过时的技术栈问题。最终只是延缓项目陷入单体地狱的速度。要从根本上解决这一问题，必须迁移到新架构：微服务架构。

1. 微服务的三个维度：对请求的负载均衡、对用户的负载均衡、以及对服务的模块化。

2. 每个服务都拥有自己的数据库：服务之间是松耦合的，它们仅通过API进行通信。当然，这并不意味着每个服务都需要一个独立的数据库服务器。

 

优点：

1）使大型的复杂应用程序可以持续交付和持续部署

它拥有持续交付和持续部署所需要的可测试性、可部署性，并且开发团队能够自主且松散耦合。

因此带来的价值有：

1. 业务同事满意：缩短了产品交付时间。

2. 客户满意：提供可靠服务。

3. 项目组成员满意：可以花更多时间来提供有价值的功能，而不是四处担任救火队员。

2）每个服务都相对较小并容易维护。

3）服务可以独立部署和扩展

每个服务都可以部署在适合它们需求的硬件上，例如有些组件是CPU运算密集型的，有些可能需要更多的内存空间。

4）微服务架构可以实现团队的自治。

5）更容易实验和采纳新的技术

当开发一个新的服务时，开发者可以自由选择适用于这个服务的任何语言和框架。

6）更好的容错性。

 

缺点：

1）服务的拆分和定义是一项挑战

要尽量避免构建出一个分布式的单体应用：一个包含了一大堆互相之间紧耦合的服务，却又必须部署在一起的所谓分布式系统。

2）分布式系统带来的各种复杂性，使开发、测试和部署变得更困难

服务必须使用进程间通信机制。必须设计服务来处理局部故障，并处理远程服务不可用或出现高延迟的各种情况。

基于微服务的应用程序必须使用所谓的Saga来维护服务之间的数据一致性，必须使用API组合或CQRS视图实现查询。

运维复杂性：

1. 自动化部署工具，例如Netflix Spinnaker

2. 产品化的PaaS平台，例如Pivotal Cloud Foundry或Red Hat OpenShift 

3. Docker容器编排平台，例如Docker Swarm或Kubernetes

3）当部署跨越多个服务的功能时，需要谨慎地协调更多开发团队

当部署跨越多个服务的功能时，必须制定一个发布计划，把服务按照依赖关系进行排序。

4）开发者需要思考到底应该在应用的什么阶段使用微服务架构

在开发应用程序的第一个版本时，通常不会遇到需要微服务架构才能解决的问题，反而，使用精心设计的分布式架构将减缓开发速度。所以，针对初创公司来说，最大的问题通常是在快速发展业务模型和维护一个优雅的应用架构之间的取舍。特别是在开发MVP场景时，初创公司的初版应用程序是用来获取市场或投资人的反馈、进行快速试错的，这个阶段不应花费太多时间在微服务架构这样的事情上。