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

导言：

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

首先献上微服务的技术点思惟导图：

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

第一步，解耦现有模块

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

第二步，抽取公共模块

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

1）作好代码控制

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

2）作好版本管理

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

第三步，解耦迭代需求

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

第四步，配置解耦

为每一个模块每一个环境配置一个配置文件，这样就能够把不一样的环境的配置解耦，不用每次上线都更新一次。可是若是须要修改数据库配置，仍是须要从新部署重启应用才能解决。使用微服务的配置中心就能解决这个问题了，好比使用ZooKeeper做为SpringCloud的配置中心，修改ZooKeeper中的节点数据就能够实时更新配置并生效。

第五步，权限解耦

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

第六步，流量解耦

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

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

第七步，数据解耦

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

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

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

第八步，扩容解耦

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

第九步，部署解耦

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

第十步，动静解耦

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

总结

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

事实上，微服务架构短时间来看，并无很明显的好处，甚至短时间内会影响系统的开发进度，由于高内聚，低耦合的系统对开发设计人员提出了更高的要求。高内聚，低耦合的好处体如今系统持续发展的过程当中，高内聚，低耦合的系统具备更好的重用性，维护性，扩展性，能够更高效的完成系统的维护开发，持续的支持业务的发展，而不会成为业务发展的障碍。

最后

欢迎你们关注我新开通的公众号【风平浪静如码】，最新最全多家公司java面试题整理了1000多道400多页pdf文档，文章都会在里面更新，整理的资料也会放在里面。

喜欢文章记得关注我点个赞哟，感谢支持！