不能在举行大促时发券时，我线下支付一直支付不了，这是非常严重的事故了，客服电话会被打爆了 。所以，必须要对流量进行拆分，各个端的流量不能相互影响，比如App端、微信端、运营后台和商户后台等都要分配独立的Gateway，并接入独立的带宽，对于流量大的端可以使用弹性带宽，对于运营后台和商户后台就比较小的固定的带宽即可 。这样就大大降低了升级时的难度，是不是再上线时就没那么紧张了？
第七步，数据解耦系统刚上线的时候，数据量不大，所有的模块感觉都挺好的，当时间一长，系统访问量非常大的时候会发现功能怎么都变慢了，怎么MySQL的cpu经常100% 。那么恭喜你，你中招了，你的数据需要解耦了 。
首先要模块间数据解耦，将不同模块使用独立的数据库，保证各模块之间的数据不相互影响 。
其次就是冷热数据解耦，同一个模块运行时间长了以后也会积累大量的数据，为了保证系统的性能的稳定，要减少因为数据量太大造成的性能降低，需要对历史数据进行定期的迁移，对于完整数据分析汇总就在其他的库中实现 。
第八步，扩容解耦一个好的架构设计是要有好的横向扩展的能力，在不需要修改代码只通过增加硬件的方式就能提高系统的性能 。SpringCloud和Dubbo的注册中心天生就能够实现动态添加模块的节点，其他模块调用能够实时发现并请求到新的模块节点上 。
第九步，部署解耦互联网开发在于能够快速的试错，当一个新的版本上线时，经常是需要先让一部分用户进行测试一下，这就是传说中的灰度发布，同一个模块先部署升级几台服务器到新版本，重启完成后流量进来以后，就可以验证当前部署的这几台服务器有没有问题，就继续部署其他的节点，如果有问题马上回滚到上一个版本 。使用SpringCloudGateway的WeighRouterFilter就能实现这个功能 。
文章插图
第十步，动静解耦当同一个模块的瞬间有非常高并发的时候，对，就是说的秒杀，纯粹的流量解耦还是不够，因为不能让前面的流量冲击后面真正的下单的功能，这个时候就需要更细的流量解耦，要将静态文件的访问通通抛给CDN来解决，动态和静态之间是通过定时器来出发的，时间未到之前一直刷新的是静态的文件，当时间到了之后，生成新的js文件，告诉静态页面可以访问下单功能了 。
总结在模块划分时，要遵循“一个模块，一个功能”的原则，尽可能使模块达到功能内聚 。
事实上，微服务架构短期来看，并没有很明显的好处，甚至短期内会影响系统的开发进度，因为高内聚，低耦合的系统对开发设计人员提出了更高的要求 。高内聚，低耦合的好处体现在系统持续发展的过程中，高内聚，低耦合的系统具有更好的重用性，维护性，扩展性，可以更高效的完成系统的维护开发，持续的支持业务的发展，而不会成为业务发展的障碍 。
【我仅用10步，就写出了全网最全的微服务架构详解】
推荐阅读
- 梦见一捆一捆的韭菜我拿了一捆 梦见一捆一捆的韭菜烂了
- 梦到去世的爷爷和我说话和我笑 梦到去世的爷爷和我说话是托梦吗
- 茶最早被加工成茶饼之溯源
- 走进紫阳 领略茶乡风韵
- 如果发生核战，我们应该躲到哪里？专家：这3个地方比较安全
- 小个子答应我，穿长裙时尽量少配高跟鞋！显矮又拖沓，试试这三种
- 大小不同的内存，也能组双通道吗？
- 春季吃什么 春季八款养生大美食
- 一口气看完地球的历史
- 治疗盆腔积液的药有哪些