导读：

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

SpringCloud和Dubbo是目前成熟的微服务框架，如何用两者构建你的微服务系统？ 他们是怎么解除结合你的系统的？ 是怎么解除结合的呢？ 请慢慢听：

第一步是解除现有模块的结合

通过使用微服务器框架，可以很容易地重新设计现有的合并模块，使其成为可以独立部署的多个模块。 成熟的示例代码特别多，在此不多赘述。 以下是我的微服务实现的体系结构设计图。

步骤2、提取公共模块

架构设计的原则之一是反向依赖，只能从上到下依赖，所以要提取共同的重复功能模块。 需要强调的是，通用模块必须功能足够单一，不能有其他业务的逻辑判断zydbb。 整个模块依赖关系必须是树结构关系图，而不是网格关系图。

1 )代码控制

笔者以前就遇到过这样的问题，当模块划分完毕，需求发生变化时，研发人员无论是公共模块还是公共模块，只要能够快速完成任务，都可以做到随时随地、即时随地。 因此，这需要在内部进行代码权限管理，不应该开放向所有人提交代码的权限。 之后，我恢复了公共模块连接代码的权限。 合并代码必须提交申请，然后通过代码review合并代码。 这样可以保证通用模块代码的功能是单一的。

2 )做好版本控制

通用模块被多个模块模块使用，更改代码可能会导致使用中的模块无法使用。 这需要对各个模块进行版本管理。 我用maven做版本管理。 定义父pom项目进行各模块的版本控制。 其他模块使用的所有开发包都在父pom中进行版本控制。 出现新需求后，需要修改通用模块时，要更新模块的版本号，同时更新父pom的版本号，需要使用通用模块新功能的模块修改父pom的版本号。 不使用通用模块新功能的模块不修改父pom的版本号，可以使用通用模块的新老版本，即使出现问题也只影响使用新版本的模块。

步骤3、消除反复的需求

当前代码迭代速度快，同时面临多个需求，有的需求紧急，有的需求不紧急，而且紧急程度随时可以调整。 当你把所有的需求放在一个分支，只想在线化其中的一些需求时，你发现不能分割不在线化的需求的代码，很尴尬吗？ 即使可以分割，修改代码后再次进行部署测试也很费时间和精力，所以必须针对不同的需求建立新的研发分支。

步骤4、构成去耦器

通过为每个模块的环境配置配置文件，可以取消对不同环境的配置，而无需每次联机都更新。 但是，如果需要更改数据库配置，则必须重新部署并解决重新启动的APP应用程序。 使用微服务的配置中心可以解决这个问题。 例如，如果将ZooKeeper用作SpringCloud的配置中心，则可以通过修改ZooKeeper的节点数据实时更新和启用配置。

步骤5，取消合并权限

如果采用微服务器架构将原系统划分为多个系统，就会发现原简单的问题，现在变得复杂了。 例如，功能的权限控制，原本是和业务代码一起的。 现在，如果每个业务模块都有功能权限的代码，就会非常麻烦。 那么，解决方案是转移权限功能。 碰巧用SpringCloudGateway就可以做这件事。 SpringCloudGateway可以平衡负载，可以进行各种根阻塞。 只需将原权限控制代码迁移到网关中实现以下操作即可，权限配置管理界面和代码逻辑均不变： 如果是API接口，将安全认证等功能放入网关进行安装即可。

步骤6、流量去耦

当顽皮等大碗系统的访问量增加时，你会发现每次升级都非常麻烦。 领导者不能在这个功能忙的时候停机影响用户的使用，或者只能半夜升级，多么痛快啊！ 有些运营人员可能会注意到，为什么我的后台访问这么慢。 问题在哪里？ 问题是所有的模块都使用一个网关，在多端同时使用同一个通信入口。 在进行大规模促进时，如果并发量非常高，带宽非常大，其他功能也会变慢。

不能着急发行票的时候，我不能在网上付款了。 这是非常严重的事故，回叫电话会破裂。 因此，必须划分流量，各终端的流量互不影响。 例如，APP端、微通道端、运营后台、商户后台等必须分配独立的网关，接入独立的带宽，对于流量较大的终端可以使用灵活的带宽，运营后台这样会大大降低升级时的难度，在线的时候就不会那么紧张了。

步骤7、数据去耦

系统刚上线的时候，数据量很少，所有的模块都感觉很好。 随着时间的推移，如果对系统的访问量非常大，无论如何都会发现功能变慢。 怎么mysql的cpu总是100%。 那么恭喜你。 请在你体内采取措施

了，你的数据需要解耦了。

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

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

第八步，扩容解耦

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

第九步，部署解耦

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

第十步，动静解耦

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

总结

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

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