我仅用10步，就写出了全网最全的微服务架构详解 _微服务

导言：

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

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

文章插图

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

文章插图

第二步，抽取公共模块架构设计原则之一就是反向依赖，只从上往下依赖，所以，我们将公共的重复功能的模块抽取出来。必须强调一点的是，公共模块必须足够的功能单一，不能有其他业务的逻辑判断在里面。在整个模块依赖关系里，应该是一棵树状结构的关系图，而不是一个网状的关系图。
1）做好代码控制
笔者之前就碰到过这种问题，模块划分完了，当需求变更的时候，研发人员根本不管是不是公共模块，只要能快速完成任务，哪里改的快就在哪里改。因此，这个需要内部要做好代码的权限管理，不应该开放所有的提交代码的权限给所有的人。后来我就将公共模块的合并代码的权限收回了，合并代码需要先提交申请，代码review过才能合并代码。这就保证了公共模块代码的功能单一。
2）做好版本管理
公共模块被多个模块模块使用，任何代码的修改都可能会导致到正在使用的模块无法使用。这个就需要做好各个模块的版本管理，我是使用maven进行版本管理的，定义一个总的父pom项目来进行各个模块的版本管理，任何被其他模块使用的开发包都要在父pom里进行版本管理。当新的需求来了以后，需要对公共模块进行修改时，要更新模块的版本号，同时更新父pom的版本号，需要使用公共模块新功能的模块就修改父pom的版本号，不需要使用公共模块新功能的模块就不用修改父pom的版本号，这样公共模块的新老版本都能使用，即使出现问题，也只会影响到使用新版本的模块。
第三步，解耦迭代需求现在的代码迭代速度快，同时会面对多个需求，有的需求紧急，有的需求不紧急，而且紧急程度可能随时会调整，如果将所有的需求都放在一个分支，当只想上线其中几个需求的时候发现无法将不上线需求的代码拆分出来，是不是很尴尬，即使能拆分出来，代码修改过以后又要重新进行部署测试，很费时费力，所以要针对不同的需求重新建立研发分支，这样就将不同需求的分支解耦，保证想上哪个就上哪个，需要上多个需求的就将分支合并上线。
第四步，配置解耦为每个模块每个环境配置一个配置文件，这样就可以把不同的环境的配置解耦，不用每次上线都更新一次。但是如果需要修改数据库配置，还是需要重新部署重启应用才能解决。使用微服务的配置中心就能解决这个问题了，比如使用ZooKeeper作为SpringCloud的配置中心，修改ZooKeeper中的节点数据就可以实时更新配置并生效。
第五步，权限解耦当采用微服务架构把原来的系统拆分成多个系统以后，你会发现原来简单的问题，现在变的复杂了，比如功能的权限控制，原来是跟业务代码放到一起，现在如果每个业务模块都有功能权限的代码，将是一件非常麻烦的事情。那么解决办法就是将权限功能迁移出来，恰巧使用SpringCloudGateway就能完成这件事情，SpringCloudGateway能够进行负载均衡，各种路由拦截，只要将原来的权限控制代码迁移到Gateway里实现以下就可以了，权限配置管理界面和代码逻辑都不用变。如果是API接口呢，就需要将安全验证等功能放在Gateway里实现就好了。
第六步，流量解耦当你的系统访问量越来越大的时候，你会发现每次升级都是一件非常麻烦的事情，领导会跟你说这个功能忙时不能停机影响用户使用呀，只能半夜升级呀，多么痛快的事情啊。有的时候运营人员也会发现，怎么我的后台访问怎么这么慢？问题出在哪里呢？问题就出在，所有的模块都用了一个Gateway，多端同时使用了相同的流量入口，当在举行大促时，并发量非常高，带宽占用非常大，那么其他的功能也会跟着慢下来。