系统架构设计时到底要不要采用微服务架构？
系统架构设计时到底要不要采用微服务架构？
文章目录
- 系统架构设计时到底要不要采用微服务架构？
-
- 前言
- 观点一：单块优先
- 观点二：微服务优先
- 总结
- 公众号
- 参考
前言
本文主要回答一个问题：为什么要采用的微服务架构？
我们经常看到大家在争论到底要不要采用微服务架构的问题。
有的人认为微服务太复杂了，不太适合初创企业的应用，单块应用更简单，更适合这种初创应用。
而有的人则认为微服务架构是整个互联网应用架构的趋势，很多传统企业也在不遗余力的将现有的单块应用改造成微服务架构。
那么到底要不要用微服务架构？有没有参考标准？是一个大家都很感兴趣而且有争议的话题。
要不要采用微服务架构？对于这个问题，目前主要有两种主流的观点。
观点一：单块优先
第一种观点的认为企业应用是否要微服务化的这个判断标准，主要看企业业务发展的阶段和规模，业务发展早期的话，建议采用单块架构，随着业务的不断发展和扩张，也随着对业务领域的不断深入理解再逐步拆分，就演化出微服务架构。
大家可以看到，目前业界主流的一些互联网公司，国内比如说像阿里巴巴和携程，国外像Netflix还有eBay等等，这些公司起步阶段因为规模小，一般都是采用单块架构。
但是随着业务和团队规模的不断扩张，原来单块架构逐渐成为阻碍业务规模化和快速创新的瓶颈。所以，这些公司大都经历过一个拆分结构的过程，不断的将其应用服务按照业务领域或者团队边界进行拆分，以适应业务和团队不断扩张的需求。而且这个结构拆分的过程会一直持续演进下去。
所以，企业应用要不要微服务化，主要看现有的系统架构和企业的业务团队发展速度之间是否匹配？是否有矛盾？
- 如果单块架构严重阻碍了企业业务和团队的进一步发展，那么就需要视情况进行逐步的解构拆分。
- 如果企业业务还在发展初期，本来业务和团队规模就不大，或者业务发展速度和系统架构之间没有矛盾。那么就没有必要急着去搞微服务，如果纯粹只是为了微服务而去搞微服务，那么由于微服务引入的技术复杂性，可能反而会阻碍业务的正常发展。
软件技术有个大牛，叫 Martin Fowler ，他是这种观点的主要的支持者。
原文地址：https://martinfowler.com/bliki/MonolithFirst.html
上面这个图是来自 Martin Fowler 的博客的上面的一篇文章，他是主张应用开发应该优先考虑单块，也就是 Monolith first。
如果一开始就考虑微服务，因为对业务领域不熟悉，没办法正确的把握业务领域边界的划分，所以失败风险比较高，如果先以单块开始，你就可以赢得更多的时间去探索业务领域的复杂性，对业务领域的边界会有更深入的理解。
在这个基础上，再根据业务和团队规模发展的需要逐步拆分出微服务。这种方式风险相对就比较低，所以这个图上如果说你直接走向微微服务的话，风险是比较高的。如果先从单块开始，然后逐步拆分，那么这个风险会相对比较低。这是单块优先的理念。
微服务引入时机
下边还有一个图，也是引自 Martin Fowler 博客，这个图主要是讲微服务引入的时机，什么时候该引入微服务。
原文地址：https://martinfowler.com/bliki/MicroservicePremium.html
那么，Martin Fowler 认为，企业应用刚开始并不复杂，如果一开始就采用微服务架构，因为微服务需要基础设施这些额外的技术支持，企业就需要额外的投入去搞这些微服务基建。所以生产率反而不如单块应用，当企业的业务复杂性和团队规模到达一个点，那么单块应用由于耦合等因素，生产率会急剧下滑，这个时候就需要考虑拆分成微服务。
当到了某个点单块应用的生产率反而会急剧下降，那么这个时候你就需要考虑拆分成微服务。引入微服务基础设施来管理这个复杂性，这个时候微服务的生产率又明显地优于单块架构，那么这个点在哪里？每个企业各不相同，因为每个企业的发展阶段、业务团队、技术架构各不相同，所以需要综合考量。
这就是第一种观点：认为应该以单块起步，逐步拆分成微服务。
观点二：微服务优先
第二种观点认为，技术的进步使得微服务架构的门槛和成本已经大大降低。微服务架构是当前互联网应用架构的首选。
以前微服架构体系不成熟，基础组件比较缺乏，一般企业去实施微服务架构，门槛和成本是比较高的。所以，应用一般不建议直接使用微服务架构。
现在，这个情况已经发生了一些根本性的变化。经过多年的行业实践和沉淀，微服务架构体系已经变得成熟，配套的微服务开源基础组件也很丰富。其中标志性的开源产品 Netflix 开源了整个微服务技术栈统称 Netflix OSS。Pivotal在 Netflix 开源的基础上再封装推出了 Spring Cloud 微服务开发套餐。然后还有 Docker 容器技术的引入，以及谷歌开源的 Kubernetes 云平台。可以说一个完整的、完善的微服务生态圈已经形成了，那么随着微服务技术门槛的降低，企业应用架构的趋势也发生了变化。
如今有不少企业在开发应用的时候，他们并没有特别考虑业务和团队规模的问题，而是一开始就采用微服务架构。因为他们发现采用微服务架构和采用单块架构的门槛和成本是一样的，那在这样的情况下。既然微服务有更多的灵活性和易于扩展的好处，那么为什么不直接使用微服务架构呢？
从软件开发方法学演进的角度来看，行业经历了面向过程、面向对象、面向组件到现在面向服务微服务的发展历程，微服务让我们能够在更高层面抽象，管理软件的复杂性，开发更大规模的系统，应对更加复杂多变的互联网需求，它是行业发展的一个必然趋势。
所以总体上，就是目前主要有这样两种观点，一种认为是应该单块优先，另外一种认为是微服务优先。
那么，根据一线互联网企业多年的实践，上述两种观点都有其合理性。都有成功案例，当然这个问题没有标准答案，具体还要结合企业的业务、组织架构和技术等上下文综合判断。即使使用微服务，它也不是一步到位的，也是一个不断演进的过程。
那么 staffjoy 公司的产品v1版本采用的是单块架构，在深入理解了业务领域之后，v2版本就重新进行设计，采用微服务架构。他的创始人在博客当中也提到，由于采用了强类型接口通讯层，并且支持 Kubernetes 容器云的一键部署。V2版本这个微服务并没有引入太多的复杂性，微服务让每个服务变得职责单一和简单，也让这个团队并行开发和交付效率变得更加灵活和高效。
总结
第一种观点：认为应该以单块起步，逐步拆分成微服务。
第一种观点的认为企业应用是否要微服务化的这个判断标准，主要看企业业务发展的阶段和规模，业务发展早期的话，建议采用单块架构，随着业务的不断发展和扩张，也随着对业务领域的不断深入理解再逐步拆分，就演化出微服务架构
微服务引入时机
当企业的业务复杂性和团队规模到达一个点，那么单块应用由于耦合等因素，生产率会急剧下滑，这个时候就需要考虑拆分成微服务。
当到了某个点单块应用的生产率反而会急剧下降，那么这个时候你就需要考虑拆分成微服务。引入微服务基础设施来管理这个复杂性，这个时候微服务的生产率又明显地优于单块架构。那么这个点在哪里？每个企业各不相同，因为每个企业的发展阶段、业务团队、技术架构各不相同，所以需要综合考量。
第二种观点：认为是微服务优先
第二种观点认为，技术的进步使得微服务架构的门槛和成本已经大大降低。微服务架构是当前互联网应用架构的首选。
经过多年的行业实践和沉淀，微服务架构体系已经变得成熟，配套的微服务开源基础组件也很丰富。其中开源 Netflix OSS 及 Pivotal在 Netflix 开源的基础上再封装推出了 Spring Cloud 微服务开发套餐。然后还有 Docker 容器技术的引入，以及谷歌开源的 Kubernetes 云平台。可以说一个完整的、完善的微服务生态圈已经形成了，那么随着微服务技术门槛的降低，企业应用架构的趋势也发生了变化。
微服务让每个服务变得职责单一和简单，也让这个团队并行开发和交付效率变得更加灵活和高效。
所以总体上，就是目前主要有这样两种观点，一种认为是应该单块优先，另外一种认为是微服务优先。
上述两种观点都有其合理性。具体还要结合企业的业务、组织架构和技术等上下文综合判断。即使使用微服务，它也不是一步到位的，也是一个不断演进的过程。
公众号
参考
《Spring Boot 与 Kubernetes 云原生微服务实践 ～ 全面掌握云原生应用的架构设计与实现》 杨波
MonolithFirst https://martinfowler.com/bliki/MonolithFirst.html
微服务引入时机：https://martinfowler.com/bliki/MicroservicePremium.html