架构系列三（微服务拆分思考）应用微服务架构的时候，我们需要考虑的成本和收益，我们说架构的本质，最终都是综合考量后的平衡方

1.引子

即便应用了微服务架构设计，许多小伙伴可能并没有机会参与到从0到1的过程，都是直接参与到某个微服务的开发实现层面上，没有从架构视角去思考过这个问题，或者说比如电商平台，怎么就拆分成了交易、订单、商品、用户、物流等子系统服务了呢？都是基于什么考量来拆分的呢？

那么有时候，哪怕作为普通开发人员，其实我们可以多想一想

今天这篇文章，我将结合我的一些实践经验和思考分享给你。让我们开始吧！

我们都知道，业界刮起微服务的风潮，大底是从14年开始的。如果再把时间向前推动2年，即12年的样子，正是移动互联网浪潮的大背景下，上网的人多了，加上企业数字化转型，应用系统的业务量、体量、复杂度一下子都上来了。

面对高并发、大流量、业务复杂，我们发现单体应用开始应付不过来，主要表现在这么几个方面

你看并发、流量、业务复杂度一旦上来，单体应用架构必然会面临以上一系列的难题。那要怎么解决呢？简单说我们可以通过八个字来说明：分而治之，化繁为简！

这就是微服务架构原生支配点，单体应用面临耦合度高、构建慢、研发效率低的问题，通过微服务架构将一个大的单体应用，拆分成一系列小的相对独立的服务。于是我们先得出一个结论：通过应用微服务架构，最大的一个收益是解耦。解耦后带来的收益有

当然随着解耦收益而来的，将是一系列的成本，凡事都有代价，我们在架构设计的时候，最终也是经过综合考量后，寻求到一个相对平衡的方案。

那么这里微服务架构，带来了哪些成本需要我们去考虑呢？大概有

性能下降：单体应用模块之间的调用，都是进程内调用；微服务之间的调用，则是跨进程的rpc调用，性能上必然是下降的趋势
分布式带来的复杂性：如何保证一致性（分布式事务问题）、如何保证唯一性（分布式Id问题）、如何保证整体可用性问题等
运维复杂性：单体应用出了问题，我们只需要监控少量的服务器，看看gc日志、线程快照、堆转储，大多数时候都能定位到具体问题；微服务应用，将面临更多的服务器、更长的调用链路，对监控运维的要求会更高
架构复杂度提升：除了业务服务外，还需要一整套支撑服务（服务注册发现、统一配置管理、网关、服务容错、监控告警具体到链路、指标、日志监控等）
等等

你看以上我给你分享了应用微服务架构的时候，我们需要考虑的成本和收益，我们说架构的本质，最终都是综合考量后的平衡方案，期望在实际应用的时候给你带来一些帮助和思考。

理解了微服务架构的成本、和收益。我们再来看多维度拆分微服务，即如何把一个大的单体应用，拆分成一系列小的微服务，从0到1的过程。

我整理了一些拆分的视角，主要是结合我本人的一些实践和思考。这里你需要注意，每个团队、每个项目都是有差异的，在应用的时候一定要结合自身团队、业务的情况来考量，所谓活学活用说的就是这个意思。

因此，我更期望我的分享给你带来的是一个思考的视角，具体有哪些呢？我们看一下

业务优先原则：在所有的拆分原则中，业务一定是要放在首位的，比如说用户、商品、订单，我们都会优先从业务的角度来考虑
基于可用性、可靠性原则：不同的业务微服务，对可用性、可靠性会有不一样的要求。比如说核心业务微服务，我们可能要求5个9的可用性；非核心业务微服务，比如说后台管理、报表我们只需要3个9的可用性。这个时候我们可以考虑可用性原则
基于性能原则：类似于可用性、可靠性原则。核心业务链路上的微服务，响应时间rt可能要求毫秒级的响应；非核心业务微服务，可以接受秒级的响应时间。这个时候我们可以考虑性能原则
基于资源要求原则：IO密集型微服务对IO资源要求高；CPU密集型微服务对CPU资源要求高。这个时候我们可以考虑资源要求原则，更方便资源层面的扩容缩容
基于稳定性原则：基础服务，比如说字典翻译、参数配置稳定性高；业务服务需求变化快，业务稳定性低，要求快速迭代。这个时候我们可以考虑稳定性原则

以上我给你分享了业务优先、可用性、性能、稳定性、资源等原则，在实际应用中我们需要综合这些原则考量后，最终完成微服务从0到1的拆分过程。