【打怪升级】【微服务】聊聊微服务拆分设计

并不是所有的场景都适合微服务，我理解技术开发者都有一颗追求新技术的心，但是更重要的是业务场景及团队。

  • 关于微服务

　　微服务架构，说白了就是一种上层体系的演变。从最早的单体架构，到前后分离，SOA，甚至微服务架构，其实它们都在做一件事，并且都朝着一个方向去发展：那就是分而治之！从简！

　　分而治之有什么好处呢？ 对于服务来说，可能每个服务实例都是集群化、容器化、并且轻量级；对于设计人员就是低耦合，高内聚；

　　有了这种思想，对整体架构其实是进一步的升级。因为我们都知道微服务架构一方面也是由于对服务性能要求更好的进化。我们追求“三高”，从某种意义而言，通过叠加机器的方式更能有效的提升性能，毕竟现在的机器，甚至云服务器成本不是那么高不可攀！

　　readMe：

　　我接触过很多公司，它们的产品体系也是一步步转化而来的！很多产品设计的前期，都追求快速上线，功能正常，并不需要太多的设计，但是慢慢产品体系、功能模块甚至日活到达一个量级后，会做一些上层的设计拆分，重构，它们的目的是为了满足我们具体的业务场景更流畅、甚至交付更快速等等...

　　在技术讨论交流中，很多开发者对上层设计甚至架构能力会持有不同的看法，比如某某功能模块业务边界、是否应该做服务拆分、是否需要上微服务生态，而且大部分开发者和领导决策层往往会有不同的看法，因为大家站在角度不同：如果是技术开发者，更习惯于追求新的技术，或者希望做出一定的改变。但是对于管理者甚至技术CEO往往会从不同的角度思考：微服务带来的问题、微服务业务边界、微服务DDD领域模型、以及上层聚合数据中台或业务网关。

 

  • 微服务带来的问题

　　技术选型其实就跟买衣服一样，看着好看的衣服不一定合身、也不定适合你；适合你的可能你会一开始觉得很一般，但是穿起来会很舒服！

　　我们不妨思考一下，如果你们的公司产品现在是一个单体架构，从现有的结构上考虑，如果做微服务拆分，会有哪些棘手的事情？

  1. 微服务生态组件的选择
  2. 服务拆分边界　　
  3. 微服务数据聚合问题
  4. 线上监控、排查
  5. 分布式老生常谈的问题 ：数据一致性
  6. 如果目前是单体服务，从哪些角度进行拆分靠谱

　　

　　微服务生态组件：目前以java的生态为例，目前基于springcloud、springcloud&alibaba或者zookeeper dubbo 都可以实现分布式架构，当然它们也会有有缺点，比如nacos CP AP的选择、cloud config的运维配置、持久化、这个可以根据团队的技术方向、以及具体业务考虑、但是这往往是最简单的一步，因为我相信很少有公司会自己写分布式组件、像阿波罗或者其他组件，很多公司都是拿来即用即可。

　　服务拆分边界：这个是一个棘手的问题，往往前期做服务拆分会伴随着各种各样的问题。比如我们应该根据功能模块进行拆分还是根据场景压力进行拆分？各个服务之间耦合性怎么控制？

　　微服务数据聚合：往往我们有这么一个场景、例如我的用户服务和订单服务是两个独立的微服务，但是有些场景我需要将各自的数据聚合查找，这种方式怎么处理？

　　线上监控、排查：微服务通信，主要还是采用rest或者异步MQ的方式进行通信的，那么一个场景多个服务直接调用，如果发生异常我们怎么排查问题？

　　数据一致性：每个服务都有自己的数据，怎么保证数据一致性？

　　单体演变微服务过程：如果我现在是一个单体服务，我需要做微服务拆分，慢慢将架构转变到微服务架构，怎么做？

 

  • 微服务带来的好处

　　有了微服务带来的问题，那么我们要考虑微服务带来的好处有哪些？

  1. 微服务基于容器部署，单个服务相比较小，快速启动
  2. 每一个服务都是一个独立的server、不于其他服务向耦合
  3. 如果需要敏捷开发，微服务一定是最适合的，服务拆分可以快速迭代，不需要整体发布
  4. 服务单一职责，任务拆分
  5. 缓解业务场景压力，比如某个服务压力大，粗暴加机器扩容
  6. 很多公共组件可以抽象出来，避免重复造轮子
  7. 交付场景某种意义更适合

 

　　部署：基于容器自动化部署，更方便，更迅速

　　敏捷开发：敏捷开发一定是更适合微服务，如果单体要考虑敏捷迭代，合并甚至其他一系列问题

　　单一职责：可以由技术团队去控制服务的分配，目标更明确

　　性能：集群实例，这个没什么说的，毕竟现在机器的成本不大。而且如果是单体出现性能问题，那么可能上层做负载，下层的服务很笨重

　　公共组件：很多公司会有这样的程序员，我们在一个单体开发，很多类似的功能每个人都会造一套轮子，冗余代码超级多。

　　交付：这个不同公司的情况是不一样的，举个我们之前的公司，我们基于产品做开发，这时候每次有交付就会从产品拉一份然后做二开，而且交付场景也很笨重。例如某些客户只想要我们的A不想要我们的B，它只给A模块付费，那么传统的方式就是lic控制，把B禁掉，这是一个很繁琐的流程

　　

  • 如何解决微服务的问题

服务拆分问题

 

　　服务拆分，其实总体思想很简单，就是一个服务要做什么事情？有了这个结论，其实我们就可以做服务拆分了。

　　具体一点，就是：单一服务高内聚低耦合，每个服务只需要关系自己干的是什么事情就够了，例如用户服务，那它只应该管用户的事情，如果这时候它又要管订单的职责，那么这个服务边界就是一个不合理的。这样有个好处就是，用户服务发生改变不需要处理其他服务的代码，当然（如果对外提供对应的api发生变化，那没有办法，当然也有办法避免，各有好坏）

　　但是，在某些场景下，有可能服务违背了这个原则：（就跟数据库设计三大范式，它是一种规范，但是它不适用所有场景！）例如几何耦合性很高的服务，同时又大量有服务聚合的场景，那么它需要拆吗？很明显它是不需要的，何苦给自己找罪受呢？要知道服务多了也会有问题，整体架构会更加复杂！

　　如果我是一个单体项目，我要开始做服务拆分应该怎么做呢？首先，拆分的过程一定不能影响目前迭代的进度。一个不完善的服务想去拆分，往往最后的结果是拆不如不拆！我们可以先从相对独立的模块进行拆分，比如通知服务，或其他，它的选择应该是核心功能很明确，并且业务耦合性不高，而且趋于稳定。

　　同时，在考虑服务拆分的时候，一定要结合业务场景！要了解业务模型后，整理出比如对外提供的结构、设计、甚至一些api之后，再考虑这件事情！举个例子：如果我们有两个服务，它们本身有一定的依赖，但是它们被拆分了，那么某个场景的动作应该就是A服务调用 -> B服务调用。如果我们有大量的场景需要数据聚合，那么这两个服务是否应该拆分呢？往往我们得出的是否定的结论，除非处于其他的角度，比如这个服务场景性能要求或者其他。

　　所以，服务拆分一般来说主要取决这么几点方式：

　　　　基于业务模块：业务A是一个服务、业务B是一个服务

　　　　公共拆分：我们会有很多基础的服务，这些是业务提供的核心，但它们往往不需要变动，就需要将上层抽离出来，那么往往我们再变动业务，只需要关心具体的业务变动就好了，不需要考虑基础建设（试想一下，如果每个业务处理都要伴随着基础模块修改，然后其他的业务又都依赖于这个基础模块，那是不是乱套了？只要发生变动就会从头改到尾，或者针对变动单独写一套，周而复始这个代码得屎山成什么样？）

　　　　场景拆分：比如某个场景很重要，对性能要求很高，那么可以将这个抽出来，针对这个服务进行优化

 

数据一致性

 

　　微服务要保证数据一致性，但其实这也是个死命题，例如CAP，要保证高可用就要牺牲部分一致，鱼和熊掌不可兼得！想想我们的服务都是通过网络去通信的，再好的方式也避免不了网路抖动。这里想到了之前有一个面试官跟我聊过的微服务数据库短暂不一致的问题：如果我们通过主从 binlog同步，会有短暂的不一致。master写入数据还没来得及同步到slave，那这时候slave没有数据，怎么办？其实这个问题不需要解决，很多场景我们允许短暂不一致，但是我们要保证最终一致性！再者如果要求这么高，可以将同步方式设置为串行同步，写数据就立刻刷到slave，同步完成后再返回，那么主线程就会有短暂的阻塞，这个看业务的取舍了。

　　那么，从微服务数据读写来说，我们要关注的问题是：数据一致性读、数据一致性写、操作幂等。

 

　　首先我们来说说幂等，这个我相信更多在第三方sdk、暴露服务、甚至MQ消费过程中会用的更多，它的本身含义是：相同的参数在同一个方法里，无论执行一次还是多次都会响应相同的结果！

　　对于查询和删除，其实本身就是幂等的。只要数据没有变化，那么多次查是没有问题的。至于删除，如果你想删除一个已经删除的元素应该怎么做？那就不操作了呀，反正已经删了。

　　新增数据的幂等，这个有很多种方式控制，例如通过key签名校验、客户端防抖、甚至unique唯一索引都可以做到。

　　修改数据的幂等，就是一个相对复杂的问题了。首先，并发问题下会导致数据重复修改导致脏数据，第二来说也会导致获取的是脏数据。例如我查询和修改同时进行，查询的数据可能是还没来得及修改的数据。

　　所以 这里引申出的几种方案，分别是读写共享锁、乐观锁ABA，一方面控制并发处理，一方面控制数据安全。

 

　　数据一致性读，这个不是但个服务的查询，而是服务之间的数据处理。具体请看数据聚合模块。

　　

　　数据一致性写，写的一致性说白了，就是分布式事务。我们知道分布式事务是一个很繁琐的问题。分布式事务主要有这么几种方式：TCC、XA二阶段提交（seate）、异步事务中间件、异步请求、回调补偿等等

　　首先我们说最特殊的，异步事务中间件：举个例子：Rocket的分布式事务消息，TCC+本地消息表的变种，具体请查看：【打怪升级】【rocketMq】如何保证消息零丢失

　　其实，更多时候我们通过seata或者其他全局事务中间件去处理，使用方便，集成简单。

　　常规的场景不过多描述，但是在某些业务场景下还有其他的处理方式：例如事务场景也有等级之分，那么核心的事务执行完成后，要保证其他事务必须完成。举个例子：电商下单完成后，可能需要调用会员积分，给账号加积分。那我们允许积分没加成导致的下单回滚吗？很明显是不行的。这种情况我们会将失败但必须要完成的事务操作缓存起来，让异步线程或者其他操作去重新执行，如果一直执行失败我甚至可以直接操作数据库（特定场景...）保证这个数据没有问题。

　　

服务聚合问题

 

　　微服务数据聚合问题，是一个比较常见的问题。通常我们会有这样一个疑问，如果我的两个服务需要关联查询数据怎么办？

　　首先，给出结论：常见的方式有这么几种：

  1. 部分冗余字段，违反数据库范式
  2. 广播数据（binlog主从）
  3. 上层聚合服务
  4. 内存整理数据，例如服务A先查出一部分数据 然后拿着数据去查B

 

　　上面的几点，其实都是我们常用的方式，那么我们在设计中如何选择呢？

　　首先，部分冗余字段是大家的常见手段。这种方式实现起来很简单，但是它的问题是对应的数据更新后要及时同步到冗余字段里，所以它更适合比较重要但是不常变动的列上。

　　广播数据，说白了就是mysql binlog主从同步，mysql我们不光可以指定不同库的同步，也可以指定某张表的binlog 同步，那说白了其实它只适用一种场景，就是数据统计数据整理，你想想有一个服务它的db包含其他服务的db，并且它的db数据由其他服务db同步而来，这种其实违背了微服务的设计原则，这种只适合做复杂查询、复杂关联、甚至报表统计之类的场景需要。可以通过sql处理过滤很多数据。

　　上层聚合服务，这个方式也用的很多。最常见的方式是例如我们有AB两个服务，但是api有很多AB关联查询的大量场景，并且这个服务一般是需要暴露API的，那这种方式就会更好，因为如果api变动只需要考虑上层聚合服务的变动，而底层服务变动只需要考虑api的变动，对于外在是不感知的。但是它会导致我们的结构更繁琐，根据业务场景慎用，毕竟它增加了多维护一个服务的压力。

　　内存数据整理，这个从字面意思大家已经知道它是什么了。例如在数据量很小的情况下，我将AB的数据都查出来内存处理就够了；或者业务以A为主，我先查出A的数据，然后根据A的数据查出B的数据

　　

微服务监控运维

　　微服务的运维监控主要分为这几部分：线上问题排查、自动化运维监控、调用链路

　　对于开发者来说，这个角度其实就转换成：线上日志、链路追踪、系统监控指标

　　

　　首先，很多微服务生态日志都采用kfaka + ES + kibana，因为如果服务数量庞大，你不可能切换各种服务登陆上去看对应的服务log，所以更好的是把所有服务的实时日志收集起来，统一存储ES，并且不同服务不同场景有不同的key方便排查。再通过ES的索引进行搜索。这样运维也可以通过kibana去实时查看日志信息。

　　再者，我们的服务调用可能会有很多层，这是针对服务调用链路追踪也是一个必要的场景，比如通过Zipkin集成做服务链路调用追踪。

　　系统监控，这个就很常见了。现在很多公司喜欢采用Kubernetes，通过Kubernetes也可以做一些线上系统监控。

　　举个场景，例如某个场景业务出现问题，那么排查的第一思想就是：哪个模块哪个接口出现问题？问题的症状？服务的状态？其实这恰恰是上文说的几个问题的体现。

　　

微服务和SOA，DDD

　　很多人喜欢把微服务和SOA放在一起。其实SOA跟微服务的角度是不同的。SOA的思想是服务横向拓展能力：说白了就是通过SOA思想达到服务耦合的过程。

　　我们都知道SOA中有ESB消息总线，那么其实SOA更像一个服务网关、甚至是一个上层业务网关：因为SOA体现的能力就是服务间各自独立，但是某种规范、甚至方式将服务间的处理联合起来，这么看它是不是更像一个上层的业务网关？

　　而微服务主要体现在架构设计上，微服务的思想就是服务分而治之，每个服务职责单一，至于你怎么通信，怎么聚合其实根据个人的选择了。

　　

　　再来说DDD，DDD理念很多人第一印象就是服务拆分思想。其实这个角度没有错，我最开始也认为DDD是为了帮助我们完成服务拆分的。首先DDD的思想就是分而治之，化繁为简。那这个跟微服务设计其实不谋而合了。

　　但是一般来说，如果我们拆分某个服务，如果这个服务在业务变动或者因为其他服务而频繁变动，甚至不能在短时间内完成，需要大量的考虑其他服务带来的影响，那么其实这个服务拆分是错误的。而DDD则完全遵循了分而治之的原则，我们知道服务拆分的颗粒度由很多因素决定：场景、团队、时间成本等等... 所以DDD只是一种思想，我们抛开DDD提供的领域服务之类的概念闭口不谈，它更像一个标准，就像数据库的三大范式我们设计都满足吗？如果都满足这公司的开发人员估计要骂娘了把。

　　

写在后面

　　其实我们发现，微服务设计是一个方式，也是一种手段。它不一定适合所有的场景！例如金融或者军工行业它们就比较适合，一方面它们的周期会比较长，另一方面它们也涉及者大量的变动，甚至作为服务能力的提供者，这种是由必要的。只有这样才能满足敏捷开发，并且满足一些使用场景；那如果你们开发一个小程序，一个简单的BS，没有大的体量也没有时间成本，更没有复杂的功能模块，你问我需要拆分微服务吗？跑着就行了，拆它干嘛？

　　同时，一些做上层服务重构的团队来说，也要考虑时间成本，团队人员成本（一个开发写一个微服务？头疼？），并且实际的场景。很多公司高层不看重这些，觉得这些就是白出力，浪费时间的事情；往往等到体量上来了发觉后悔了，太过笨重成本太高都是很常见的事情。

　　tips：如果你是一个技术CEO或者团队技术老大，这些事情一定要慎重，而且要了解公司上层的想法，不然出力不讨好的锅可能就在你身上了....

　　

　　　　

　　

posted @ 2023-04-16 15:41  青柠_fisher  阅读(150)  评论(0)  编辑  收藏  举报