微服务集群工作总结(共3篇)思维导图

微服务不是万能的，更不是适用于所有场景的。在对微服务的尝试过程中，会发现某些场景下滥用或者错误设计下，也可能带你陷入灾难。

常用开源熔断隔离组件：Hystrix，Resilience4j

可以从全局，IP，userID等多维度做限流。限流的两个主要目的：1，应对突发流量，避免系统被压垮（全局限流和IP限流）2，防刷，防止机器人脚本等频繁调用服务（userID限流和IP限流）

在核心链路上，服务可以冗余它依赖的服务的数据，依赖的服务故障时，服务尽量做到自保。比如订单服务依赖库存服务。我们可以在订单服务冗余库存数据（注意控制合理的安全库存，防超卖）。下单减库存时，如果库存服务挂了，我们可以直接从订单服务取库存。可以结合熔断一起使用，作为熔断的Fallback（后备）方案。

可能很多人都听过服务降级，但是又不知道降级是怎么回事。实际上，上面说的熔断，限流，数据冗余，都属于服务降级的范畴。还有手动降级的例子，比如大促期间我们会关掉第三方物流接口，页面上也关掉物流查询功能，避免拖垮自己的服务。这种降级的例子很多。不管什么降级方式，目的都是让系统可用性更高，容错能力更强，更稳定。关于服务降级详见本文后面的内容。

缓存穿透。对于数据库中根本不存在的值，请求缓存时要在缓存记录一个空值，避免每次请求都打到数据库

缓存雪崩。在某一时间缓存数据集中失效，导致大量请求穿透到数据库，将数据库压垮。可以在初始化数据时，差异化各个key的缓存失效时间，失效时间 = 一个较大的固定值 + 较小的随机值

缓存热点。有些热点数据访问量会特别大，单个缓存节点（例如Redis）无法支撑这么大的访问量。如果是读请求访问量大，可以考虑读写分离，一主多从的方案，用从节点分摊读流量；如果是写请求访问量大，可以采用集群分片方案，用分片分摊写流量。以秒杀扣减库存为例，假如秒杀库存是100，可以分成5片，每片存20个库存。

部署隔离：我们经常会遇到秒杀业务和日常业务依赖同一个服务，以及C端服务和内部运营系统依赖同一个服务的情况，比如说都依赖订单服务。而秒杀系统的瞬间访问量很高，可能会对服务带来巨大的压力，甚至压垮服务。内部运营系统也经常有批量数据导出的操作，同样会给服务带来一定的压力。这些都是不稳定因素。所以我们可以将这些共同依赖的服务分组部署，不同的分组服务于不同的业务，避免相互干扰。

数据隔离：极端情况下还需要缓存隔离，数据库隔离。以秒杀为例，库存和订单的缓存（Redis）和数据库需要单独部署！数据隔离后，秒杀订单和日常订单不在相同的数据库，之后的订单查询怎么展示？可以采用相应的数据同步策略。比如，在创建秒杀订单后发消息到消息队列，日常订单服务收到消息后将订单写入日常订单库。注意，要考虑数据的一致性，可以使用事务型消息。

业务隔离：还是以秒杀为例。从业务上把秒杀和日常的售卖区分开来，把秒杀做为营销活动，要参与秒杀的商品需要提前报名参加活动，这样我们就能提前知道哪些商家哪些商品要参与秒杀，可以根据提报的商品提前生成商品详情静态页面并上传到CDN预热，提报的商品库存也需要提前预热，可以将商品库存在活动开始前预热到Redis，避免秒杀开始后大量访问穿透到数据库。

CI测试，持续集成测试，在我们每次提交代码到发布分支前自动构建项目并执行所有测试用例，如果有测试用例执行失败，拒绝将代码合并到发布分支，本次集成失败。CI测试可以保证上线质量，适用于用例不会经常变化的稳定业务。

性能测试，为了保证上线性能，所有用户侧功能需要进行性能测试。上线前要保证性能测试通过。而且要定期做全链路压测，有性能问题可以及时发现。

代码准备。在服务层对用户表进行增删改的地方，要同时操作新库和老库，需要修改相应的代码（同时写新库和老库）。准备迁移程序脚本，用于做老数据迁移。准备校验程序脚本，用于校验新库和老库的数据是否一致。

对于第一种微服务场景，新库可以是一个单独的数据库，对于第二种场景新库就是一个已经搭建好具备分片功能的数据库。

开启双写，老库和新库同时写入。注意：任何对数据库的增删改都要双写；对于更新操作，如果新库没有相关记录，需要先从老库查出记录，将更新后的记录写入新库，如果新库有记录则新库老库一起更新；对于删除操作，如果新库没有数据则删除老库数据即可，如果新库有数据则新库老库一起删除。对于新增操作则保证新库和老库都新增成功。为了保证写入性能，老库写完后，可以采用消息队列异步写入新库。注意：双写的操作，需要保证数据的id（主键也要相同），比如老库新增老一条id为100的数据，那么在新库中这条数据的id(主键)也是100。

利用脚本程序，将某一时间戳之前的老数据迁移到新库。注意：1，时间戳一定要选择开启双写后的时间点（比如开启双写后10分钟的时间点），避免部分老数据被漏掉；2，迁移过程遇到记录冲突直接忽略，产生冲突的原因可能是迁移迁移之前老库的数据已经存在于新库了（存在主键冲突的时间段就是双写开始时间到迁移老数据开始时间，这段时间新库已经存在了老库的一些数据），当迁移操作开始后在往新库插入相同数据将会报主键冲突等问题；3，迁移过程一定要记录日志，尤其是错误日志，如果有双写失败的情况，我们可以通过日志恢复数据，以此来保证新老库的数据一致。4.老表迁移到新表的数据的主键Id也一定要一致，比如老表的数据Id为100，那么这条数据迁移到新表的id也应该为100

第3步完成后，我们还需要通过脚本程序检验数据，看新库数据是否准确以及有没有漏掉的数据对比办法：读取所有字段，根据字段名称+字段值进行拼接，拼接MD5是否相同，相同则不追究，不相同用原表进行覆盖

数据校验没问题后，开启双读，起初给新库放少部分流量，新库和老库同时读取。由于延时问题，新库和老库可能会有少量数据记录不一致的情况，所以新库读不到时需要再读一遍老库。逐步将读流量切到新库，相当于灰度上线的过程。遇到问题可以及时把流量切回老库

读流量全部切到新库后，关闭老库写入（可以在代码里加上热配置开关），只写新库

迁移完成，后续可以去掉双写双读相关无用代码。

切回单写及数据表rename当切换的新表和老表属于同一个库时，这里最好进行rename操作，也就是新表rename成老表。好处：如果老表的数据来自上游写入，那么我只需要将新表rename为老表即可，上游表对应不需要更新了。坏处：这个操作需要dba进行，且rename期间服务不可用

目前各云服务平台也提供数据迁移解决方案，大家有兴趣也可以了解一下！

全链路APM监控