读《从0开始的微服务架构》心得体会

从个人出发看微服务

在读这本书之前，我有参加过一个微服务项目的开发。这个项目的背景是公司想实验微服务架构的可行性，因此用一个小程序的电商项目作为实验。我负责分为三个模块（即三个微服务组件）：order（订单）、customer（用户）、goods（商品）。

从这个经验我简单分析一些微服务架构的利弊。（可能不正确，本人看法）

微服务使用的弊端：

1：因为使用Eureka进行注册服务，并且有Ribbon服务发现。当时架构人员把我们本机的ip地址也注册到Eureka上，导致在开发环境下，不同服务的开发人员无法每次都访问到自己的服务，即有可能访问到另一位开发人员的服务（此时另一位开发人员的开发环境的代码与自己的有区别）。因此给开发带来很大的不便。

2：因为微服务架构将整块的业务拆分成几个甚至十几个小的服务，因此在数据交互上较传统开发模式更加复杂。微服务之间的数据交互需要采用基于http方式的远程调用（例如我在开发的时候，想从订单模块获取到该订单的商品信息，需要调用商品模块的借口。商品模块也需要编写借口供其他服务调用）。对于开发人员来说，是很头疼的事情，本身只是需要一个商品的信息，却需要另写remoteservice调用（不过springCloud有一个@FeignClient注解，能够比较方便的实现不同服务的接口调用）。这点在读书之后发现不算是一个缺点，做好API的管理就好。

3：如第二点所说，微服务架构本身的优点（业务之间的松耦合）却成了头疼的事情，当然我不知道是不是数据库表设计的原因。

4：各个微服务的表结构设计很需要经验（设计需要考虑周全），否则造成各个模块之间的数据交互的不方便。

微服务使用的优点：

1：微服务将业务分成多个服务，使得各个模块之间的开发者弄清自己的业务就可以，专注于自己的业务逻辑，实现业务和代码之间的松耦合。

2：各个模块之间的调用采用借口调用的方式，这也使得开发人员必须将业务进行封装，并且暴露给其他服务进行调用。相应了人们所提倡的接口编程。并且对开发人员的编程设计习惯起到好的作用。

3：各个服务之间相对独立，一个服务断掉，并不影响其他服务的运行。因此在采用多服务器部署时，服务整块服务断掉的概率较小。

4：微服务既然将整体业务进行拆分，因此服务具有可复用性，整个模块都可以拿来使用。

 

我们是采用微信小程序作为前端视图的实现的，还有一点就是前端调用后台API时，这使得url就有三个，像这样：

CustomerURL: "http://localhost:8030/customer",

GoodsURL: "http://localhost:8060/goods",

OrderURL: "http://localhost:8070/order"

这样使得我们以前封装的request方法需要修改。

所以如果使用微服务架构，前期的准备设计工作需要考虑的比较周全。比如模块的划分，数据库设计，人员分配，接口定义（API管理），服务部署，日志管理等方面。

 

读书的学习感悟

读了这本书让我影响最为深刻的就是书中讲述的如何保障微服务之间的数据一致性，让我学到了很多知识，也整理一下学习的知识。

保障数据一致性的原因

由于各个微服务有自己独立的数据库，即传统的单架构方式的数据库根据业务拆分出来。微服务之间进行数据交互时，可能出现某些服务失败的情况，此时就出现了数据的不一致性。违背了关系型数据的ACID中的一致性。A：原子性  C：一致性  I：隔离性  D：永久性

分布式系统CAP和BASE理论

微服务架构本身是一种分布式系统，分布式系统有两个理论：CAP和BASE理论。

CAP：分布式系统的数据一致性和可用性是不可兼得的，我的理解是保证一致性的时候，当数据提交失败的时候，所有事物都将回滚，导致了系统的不可用。而保证可用性的时候，当数据提交失败时，事物不会滚，允许脏数据的存在，继续执行，这样就导致了数据的不一致性。

那BASE理论为了解决这个问题，使两种特性都退让一步，“基本可用”和“软状态”。即允许数据在短时间内可以不一致，单采用一些方法最终将数据同步。

逐渐解决数据一致性

书中首先介绍了“二阶段提交协议”。我的理解：简单来说，在数据库集群和业务层之前增加一个中间管理工具，当有事物提交时，中间管理工具通知各个数据库，做好准备，如果有数据库反馈准备失败或者无连接（如数据库宕机），则不管理工具不提交事物，直接回滚。这种做法保证了数据的一致性，但是这种做法显然影响性能。

接着引入“可靠消息最终一致性”和“TCC方案”解决微服务的数据一致性问题。

“可靠消息最终一致性”的个人理解：借鉴“二阶段提交协议”，也将事务的执行拆分为两个大步骤，利用可靠消息服务和MQ作为上下游业务数据同步的桥梁，然后针对上游业务与中间件之间、下游业务与中间件之间的各个操作步骤进行分析，对每个步骤的成功或失败采取一定的策略（比如回滚和消息重发）来保证上下游业务的数据一致性。在这个过程中，允许出现“软状态”，即短时间内数据的不一致，用来保证应用的可用性。

“TCC方案”的个人理解：同样也是借鉴“二阶段提交的”，实现方式引入三个角色：主业务、从业务 和 活动管理器（协作者）。

将事务的执行拆分为两个步骤，引入“活动管理器”作为事务的中间记录器，并且对从属业务有提交和取消的操作。流程原理在这里我不再赘述。

从我之前参与的微服务开发的角度看（猜测），因为我只作为开发人员，没有涉及架构层面，因此只能算是猜测。文中也提到了微服务之间的数据交互或者是服务调用时基于http协议的，因此我对主业务和从业务的认识如下：主业务就是直接访问的服务(url)，比如下单的动作，直接访问的是订单微服务；从业务就是在下单的同时需要积分的增加，然而积分增加是作为另外一个微服务中的业务。猜想当出现微服务之间的通信时，TCC就会出现。

 

关于API的治理

我以前参与的一个微服务应用并没有对这块的管理，这也是前期设计上的缺陷，服务之间的通信也是开发人员相互咨询之后直接调用的（当时就是三个开发者，每人负责一个服务（模块）的开发工作，比如我负责的时商品模块），那么负责订单的开发人员想要调用商品服务的接口来获取商品的信息展示时，就直接过来咨询我需要调用哪个接口、接口的参数形式等等。这样协作起来自然不是我们想要的，微服务的架构正是让开发更加便捷，因此api的管理是非常重要的。

我认为需要解决的问题有下面几个：

1.首先统一API的书写规范，比如，调用路径、调用参数、参数的说明。

2.需要确定API是每个服务都有一个文档（或者类似文档），还是全部整合在一起。

3.像书中提到的，每修改一个接口，都需要再去更改API的文档，如何解决这样的 问题。减轻开发人员的负担，并且降低容错率（文档、接口不一致的问题）。

4.书中提到的追踪API的调用，调用是否出错和原因，还有调用性能，我觉得这一 块是API治理的灵魂所在。前期的设计需要考虑到，我认为并不一定要开始就做这一块 的东西，但是需要考虑，预留给后面做这一块的空间。

本书优缺点

优点：

1.思路比较清晰，模块划分比较合理。能够通过几个章节将微服务架构的几个关键点的说明。

2.有通过微服务和单体架构的对比说明微服务在各个方面的优势和劣势，这让不熟知微服务但知道单体架构的读者能够对微服务有一个多方面的认识了解。

3.书中的第四章《保障微服务架构的数据一致性》采用的讲述方式很好，从简单到复杂让读者能够慢慢的接受讲述的知识，对我受益匪浅。

4.有些地方结合自身的项目场景这点非常好，这让读者对有些知识读完之后还能有个体现知识点的例子，更能够加深理解。

缺点：

1.对于不清楚微服务的读者来说，并不能够对微服务有个认识。

2.书中的有些知识需要一定基础的人才能看得懂，初学者可能有些懵，比如Eureka、Docker等。