聊聊微服务（一）

最近看到一些小伙伴在聊微服务相关的话题，每个人对于微服务都有自己的理解。甚至很多小伙伴觉得微服务就是架构界的“白富美”，人人都很向往拥有它，其实不尽然。任何事物脱离场景的表述都是苍白的。 那么微服务到底是什么呢？我们在什么时候需要它呢？ 在此我想拿出两年前在团队内部做过的一次分享，跟大家一起聊聊微服务。

说起微服务， 我们不得不从它是如何诞生的说起，当我们理解了它诞生的原因后，自然就会知道微服务是为何而生，生而为何。 话不多说，我们这就开始吧！

以互联网应用为例，绝大部分的应用都是从 单体应用架构 开始，随着业务的拓展及业务量的提升，逐步向 分布式应用架构 发展。而在早期的分布式应用架构中，以 SOA架构 为主，随着技术、理念的发展及更新，逐渐衍生出了 微服务架构 。

应用架构的发展日新月异，从来没有停止过它的脚步。微服务架构同SOA架构一样，同为阶段性的产物（ 近些年， Serverless架构 也逐渐进入大家的视野，开启了应用架构向“无服务器架构”模式的转变，使开发人员能够更加聚焦在业务本身的开发。 ）。 世界上唯一不变的就是变化本身  。

单体应用架构大都是以分层架构( layered-base )为基础构建的。 所谓的单体应用架构，就是将应用所有功能打包成一个独立的单元向外提供服务。 单体应用架构有其自身的优越性，非常适合初创型团队进行快速业务试错。

单体应用架构的优点：

• 技术栈单一

• 开发人员规模小

• 系统架构简单

• 运维管理、部署， 人员招聘及人员管理都相对容易实现。

随着业务的不断拓展及业务量的提升 ，单体应用架构的问题也逐渐显现出来。

单体应用架构的缺点：

• 程序耦合严重，代码扩展性差，业务逻辑复杂使得需求响应变慢。

• 业务容量存在瓶颈。各种业务代码及数据层的耦合使得服务扩展变得复杂。

• 系统可用性差。由于 代码臃肿，逻辑复杂 ，使测试难度增加，程序bug会给整个平台带来灾难性的后果。

为了解决上述的问题，分布式架构应运而生。

分布式应用架构为提升应用的扩展性、容量及可用性等问题提供了解决方案。 所谓的分布式应用架构就是将应用系统拆分为多个独立的子系统，并由各个子系统协同处理，共同向外提供服务。 对于分布式应用架构我们按时间将其分为了两个阶段， before 2010 、 after 2010 。 

▐  SOA before 2010

SOA（Service-Oriented Architecture）又叫面向服务的架构。 它是一个组件模型，它将应用程序按不同功能单元（称为服务）进行拆分，并通过定义良好的接口和协议将服务联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各类系统中的服务可以以一种统一和通用的方式进行交互 。

关于SOA架构我们可以追溯到2000年前后。那时的互联网企业都在高速扩张，很多大型的企业都面临着业务不断拓展带来的应用复杂性及容量不足等问题的挑战，正是在这种环境下，SOA架构出现了。

SOA通过对业务垂直切分，将平台的业务拆分成若干个子服务。通过这样的拆分，可以有效的解决单体应用架构所面临的问题。

SOA的优点：

• 业务及代码逻辑的复杂度降低，提升需求响应能力

• 可用性提高。 各子系统独立的开发及部署，使测试复杂度降低，bug的影响范围不会扩散至整个应用平台。

• 业务容量大。针对各个子系统的业务特点进行有针对性的优化及扩容，使优化及扩容更加简便及轻量。
  

随着时间推移， 被拆分的服务越来越多 ，随之带来问题的复杂度也呈指数上升。SOA架构的缺点逐步暴露出来。

SOA的缺点

• 系统架构复杂。

• 系统出错概率增大。
  

• 部署运维复杂度陡增。

• 研发人员规模、质量上升

• 学习曲线变大
  

• 团队协作、管理难度增加，重复功能的开发也会在团队内部造成不菲浪费

从量变到质变，SOA的这些问题给团队带来了新的挑战。随着技术、理念的发展，逐渐孕育出了 微服务架构。

▐  Microservices 2010 later

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。

微服务本质上是SOA架构的升级版 ，使用了一些新的理念及技术实现，以解决SOA架构暴露出的问题。

引用自：Microservices vs SOA: What's the Difference?[4]

2010年后，随着 领域驱动设计 、 持续集成持续部署（CI/CD） 、 虚拟化技术 、 云计算 、 基础设施自动化 以及多年来分布式架构实践过程中产生出的一些解决方案（ 服务注册发现 、 分布式配置 、 服务监控 、 服务跟踪... ）,使得分布式架构得到了长足的发展。问题、难点一个个被攻克，微服务架构正式在此基础上诞生了。

微服务的优点：

• 进一步降低了系统的复杂度。由于自动化技术的完善及领域驱动设计理念的普及，系统得到更进一步的拆分及更细的颗粒度。
  

• 组件化。更细的服务粒度，使服务拥有更高的可复用性，服务逐步组件化。

• 自动化、高可用。高度的自动化测试、集成、部署及监控，使系统运维逐渐由人工操作向AI智能化转型，使系统的弹性更优，可用性更高，故障率更低。

• 混合技术栈。团队中可以使用多种技术栈进行开发工作，针对不同业务的特点，采用更加有针对性的开发语言开发部署。

• 系统弹性可伸缩。由于采用了虚拟化、特别是容器化的部署，自动化技术的加入，系统具有高度的可伸缩性，使平台资源利用率更高。

微服务的缺点：

• 服务拆分的复杂性高。服务限界上下文[5]的错误，会导致不得不频繁的更改服务间的协作。

• 决策难度高。更细粒度的服务，意味着更高的灵活性及更多的组合，因此在设计开发中会遇到更多的决策，决策的失误会造成不必要的成本浪费。

• 学习成本进一步提高。

通过对应用架构发展脉络的梳理，我想你对微服务是什么应该有所了解了。微服务其实正是在SOA的基础上，结合了最新的理念、成熟的解决方案逐步发展而来的一个大型应用平台解决方案。

• 单体应用架构解决的是应用从0到1的问题。

• SOA聚焦解决的是提升平台容量，可用性，可维护性的问题。

• 微服务聚焦解决的是服务编排与治理的问题。

• serverless架构要解决的是让研发人员的工作能够聚焦在业务的开发。

透过问题看本质，明白了他们核心解决的问题，我想你也应该知道该如何取舍和选择了吧！所有技术架构核心是保障一个应用平台能够更稳定、高效的运转，从而达成应用平台最大化价值的目标。 为了实现目标，应用架构也只是其中的一个维度，商业的目标、市场的定位、运营的策略、组织架构...，所有这些问题及环节都需要统筹规划，协同发展才可以实现最终的目标。

微服务的话题仅凭借一篇文章很难说完，本文为了便于大家的理解，我们尽量保持在架构发展趋势这一维度跟大家进行了讲解，没有对细节深入展开，后续文章会逐渐深入讲解。 最后，感谢大家的耐心阅读，谢谢！

[1]. https://martinfowler.com/articles/serverless.html

[2]. 《谁动了我的奶酪？》是美国作家斯宾塞·约翰逊

[3].  《分布式系统原理与范型》

[4]. https://dzone.com/articles/microservices-vs-soa-whats-the-difference

[5]. 《领域驱动设计》