背景

由于前面产品A存在的隐含问题，以及交付合同中要求的微服务架构，所以在2018年下半年开始了产品A的后台微服务改造。我是8月加入了，微服务改造还在制定方案。时间紧、任务重、而且也没经验。

微服务架构是什么？

什么是微服务架构？ - 华为云开发者社区的回答 - 知乎
https://www.zhihu.com/question/65502802/answer/615568011

微服务框架有若干个选择，spring cloud，dubbo，其他是一些RPC框架。因为springcloud提供了全家桶，就选择了spring cloud。

微服务架构设计模式 ：
什么是微服务架构？ - JAVA程序员阿刀的回答 - 知乎
https://www.zhihu.com/question/65502802/answer/1145975460

改造

微服务的改造，要考虑很多
服务治理：使用eureka
网关：使用zuul
负载均衡：ribbon
限流：-
熔断：-
降级：-
配置：-
部署：运维团队支持
分布式事务：尽量在业务上避免这种情况
异步消息：暂无场景用到

剩下就是分拆单体应用了。单体应用业务众多，不清楚要怎么划分服务边界，先拆哪个。

业务分类

• 核心服务：用户信息，注册登录，配置系统
• 重点服务：一些使用频率很高，APP亮点的第三方服务、搜索服务
• 其他服务：APP上的无关服务，比如天气、弹屏、公告、意见反馈，运营后台的相关服务

根据上述分类，大体要拆出如下服务（都是假名）

• xxx1：运营后台相关功能
• xxx2：重点服务
• user：用户信息
• xxx：原单体应用

最后确定只拆用户信息，其他先不动，而用户信息这个组件的边界是用户相关表的DAO，几乎没有啥业务逻辑。而且这个用户是手机用户，运营后台的用户不算在内。

聚合层

领导想加个聚合层，用来做服务的结果做适配，或者对几个服务的结果做聚合。这也是微服务的一种设计模式。这实际上业务的代码主体放在哪里写的问题，也就是组件的服务边界划分。

1. 如果代码主体放在聚合层，在各个服务做数据的CRUD，那么服务层有可能变成大号的DAO，这不叫微服务
2. 如果代码主体放在服务组件，那么服务是可以直接对外提供服务。聚合层就只用透传，有点多余。

这两种情况都有适用的情况。

1. 客户端只需要一个简单的分页查询，那么第二个就是适用的
2. 客户端提交了一个复杂业务的请求，这个请求需要多个服务共同完成，就应该用第一个

加了聚合层后，服务加了（都是假名）

• xxx1：运营后台相关功能
• xxx11：运营后台聚合服务
• xxx2：重点服务
• user：用户信息
• xxx：原单体应用
• xxx4：移动端聚合服务

数据库

数据库这部分，他们的方案是拆出用户相关的表，而且表结构做了改动，供用户信息xxx3使用，其他的先不动。如果是我自己考虑，我会先不动数据库。等第一步完成后，再拆数据库。

灰度

改造的过程中有人考虑做个灰度，让符合要求的用户走微服务的实现，其他用户走老的实现。这个很难做到。尤其是在已经确定拆分用户相关表的情况下。

1. 因为灰度用户和非灰度用户都能查询到正确的数据，那么就要求原有库和新库的用户要时时保持相同。因为用户相关的表拆了，而且表结构改了，导致这个要求很难做到。

   • 要么在增删改的时候，做双写。双写就肯定要在原接口里调用微服务组件的接口，这个就不 满足灰度的要求。因为如果微服务接口出问题，整个系统都受影响。
   • 要么做数据库层面的同步。因为用的是MySQL，库不在同一个实例下，实现的方案没人搞过，难度较大，就没人继续研究了。

2. 如何识别灰度用户
   那么多的接口，有些是不带用户信息，有些有带，但是是不同的用户信息，比如手机号，id，token。要从多种用户标识识别出灰度用户，必须先从用户标识中获取用户信息，但是这个获取的过程本身就有可能用到微服务组件的接口。所以只能降低标准，放弃一部分的接口，放弃一些用户标识，只针对用户手机号来做。但是这样就违背了灰度的意义。

3. 如何调用灰度的逻辑
   同事在controller的requestMapping方法上加了AOP，又通过反射找到灰度controller的对应方法执行。所以有用到灰度的地方复写了一遍原有的方法，并做了响应的改变。

最后，多次讨论后，就决定不做灰度了。

所以，多次方案评审后，架构如下：

微信截图_20200524181341.png

编码

最后就是编码了

结尾

不足：

1. 数据库的拆分，尤其是表结构换了，导致拆分的工作量加大了很多，相当于用户相关的代码重写了
2. 灰度部分的讨论占用了太多时间，不过没有加灰度是件好事
3. 微服务其他部分没有考虑，先上线再说，其他后面加上