微服务架构：如何用十步解耦你的系统？

【编者的话】耦合性，是对模块间关联程度的度量。耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差。软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。高内聚低耦合，是软件工程中的概念，是判断设计好坏的标准，主要是面向对象的设计，主要是看类的内聚性是否高，耦合度是否低。

Spring Cloud和Dubbo都是现在比较成熟的微服务框架，如何使用两者构建搭建你的微服务系统呢？他们是如何将你的系统解耦的？又是怎么解耦的呢？请听我慢慢道来：

第一步，解耦现有模块

将现有耦合在一起的模块进行重新的设计，设计成可以独立部署的多个模块，使用微服务框架很容易做到，成熟的示例代码都特别多，这里不再多讲。下面是我的微服务实现的一个架构设计图。

第二步，抽取公共模块

架构设计原则之一就是反向依赖，只从上往下依赖，所以，我们将公共的重复功能的模块抽取出来。必须强调一点的是，公共模块必须足够的功能单一，不能有其他业务的逻辑判断在里面。在整个模块依赖关系里，应该是一棵树状结构的关系图，而不是一个网状的关系图。

做好代码控制

笔者之前就碰到过这种问题，模块划分完了，当需求变更的时候，研发人员根本不管是不是公共模块，只要能快速完成任务，哪里改的快就在哪里改。因此，这个需要内部要做好代码的权限管理，不应该开放所有的提交代码的权限给所有的人。后来我就将公共模块的合并代码的权限收回了，合并代码需要先提交申请，代码review过才能合并代码。这就保证了公共模块代码的功能单一。

做好版本管理

公共模块被多个模块模块使用，任何代码的修改都可能会导致到正在使用的模块无法使用。这个就需要做好各个模块的版本管理，我是使用maven进行版本管理的，定义一个总的父pom项目来进行各个模块的版本管理，任何被其他模块使用的开发包都要在父pom里进行版本管理。当新的需求来了以后，需要对公共模块进行修改时，要更新模块的版本号，同时更新父pom的版本号，需要使用公共模块新功能的模块就修改父pom的版本号，不需要使用公共模块新功能的模块就不用修改父pom的版本号，这样公共模块的新老版本都能使用，即使出现问题，也只会影响到使用新版本的模块。

第三步，解耦迭代需求

现在的代码迭代速度快，同时会面对多个需求，有的需求紧急，有的需求不紧急，而且紧急程度可能随时会调整，如果将所有的需求都放在一个分支，当只想上线其中几个需求的时候发现无法将不上线需求的代码拆分出来，是不是很尴尬，即使能拆分出来，代码修改过以后又要重新进行部署测试，很费时费力，所以要针对不同的需求重新建立研发分支，这样就将不同需求的分支解耦，保证想上哪个就上哪个，需要上多个需求的就将分支合并上线。

第四步，配置解耦

为每个模块每个环境配置一个配置文件，这样就可以把不同的环境的配置解耦，不用每次上线都更新一次。但是如果需要修改数据库配置，还是需要重新部署重启应用才能解决。使用微服务的配置中心就能解决这个问题了，比如使用ZooKeeper作为Spring Cloud的配置中心，修改ZooKeeper中的节点数据就可以实时更新配置并生效。

第五步，权限解耦

当采用微服务架构把原来的系统拆分成多个系统以后，你会发现原来简单的问题，现在变的复杂了，比如功能的权限控制，原来是跟业务代码放到一起，现在如果每个业务模块都有功能权限的代码，将是一件非常麻烦的事情。那么解决办法就是将权限功能迁移出来，恰巧使用Spring Cloud Gateway就能完成这件事情，Spring Cloud Gateway能够进行负载均衡，各种路由拦截，只要将原来的权限控制代码迁移到Gateway里实现以下就可以了，权限配置管理界面和代码逻辑都不用变。如果是API接口呢，就需要将安全验证等功能放在Gateway里实现就好了。

第六步，流量解耦

当你的系统访问量越来越大的时候，你会发现每次升级都是一件非常麻烦的事情，领导会跟你说这个功能忙时不能停机影响用户使用呀，只能半夜升级呀，多么痛快的事情啊。有的时候运营人员也会发现，怎么我的后台访问怎么这么慢？问题出在哪里呢？问题就出在，所有的模块都用了一个Gateway，多端同时使用了相同的流量入口，当在举行大促时，并发量非常高，带宽占用非常大，那么其他的功能也会跟着慢下来。

不能在举行大促时发券时，我线下支付一直支付不了，这是非常严重的事故了，客服电话会被打爆了。所以，必须要对流量进行拆分，各个端的流量不能相互影响，比如APP端、微信端、运营后台和商户后台等都要分配独立的Gateway，并接入独立的带宽，对于流量大的端可以使用弹性带宽，对于运营后台和商户后台就比较小的固定的带宽即可。这样就大大降低了升级时的难度，是不是再上线时就没那么紧张了？

第七步，数据解耦

系统刚上线的时候，数据量不大，所有的模块感觉都挺好的，当时间一长，系统访问量非常大的时候会发现功能怎么都变慢了，怎么mysql的cpu经常100%。那么恭喜你，你中招了，你的数据需要解耦了。

首先要模块间数据解耦，将不同模块使用独立的数据库，保证各模块之间的数据不相互影响。

其次就是冷热数据解耦，同一个模块运行时间长了以后也会积累大量的数据，为了保证系统的性能的稳定，要减少因为数据量太大造成的性能降低，需要对历史数据进行定期的迁移，对于完整数据分析汇总就在其他的库中实现。

第八步，扩容解耦

一个好的架构设计是要有好的横向扩展的能力，在不需要修改代码只通过增加硬件的方式就能提高系统的性能。Spring Cloud和Dubbo的注册中心天生就能够实现动态添加模块的节点，其他模块调用能够实时发现并请求到新的模块节点上。

第九步，部署解耦

互联网开发在于能够快速的试错，当一个新的版本上线时，经常是需要先让一部分用户进行测试一下，这就是传说中的灰度发布，同一个模块先部署升级几台服务器到新版本，重启完成后流量进来以后，就可以验证当前部署的这几台服务器有没有问题，就继续部署其他的节点，如果有问题马上回滚到上一个版本。使用Spring Cloud Gateway的Weight Router Filter就能实现这个功能。

第十步，动静解耦

当同一个模块的瞬间有非常高并发的时候，对，就是说的秒杀，纯粹的流量解耦还是不够，因为不能让前面的流量冲击后面真正的下单的功能，这个时候就需要更细的流量解耦，要将静态文件的访问通通抛给CDN来解决，动态和静态之间是通过定时器来出发的，时间未到之前一直刷新的是静态的文件，当时间到了之后，生成新的js文件，告诉静态页面可以访问下单功能了。

总结

在模块划分时，要遵循“一个模块，一个功能”的原则，尽可能使模块达到功能内聚。

事实上，微服务架构短期来看，并没有很明显的好处，甚至短期内会影响系统的开发进度，因为高内聚，低耦合的系统对开发设计人员提出了更高的要求。高内聚，低耦合的好处体现在系统持续发展的过程中，高内聚，低耦合的系统具有更好的重用性，维护性，扩展性，可以更高效的完成系统的维护开发，持续的支持业务的发展，而不会成为业务发展的障碍。

原文链接： https://mp.weixin.qq.com/s/GVxVNZhg_2BPzDaNygAMMQ