2.理论篇-灵析社区

俗话说，没有最好的架构，只有最合适的架构。微服务架构也是随着信息产业的发展而出现的最有普遍适用性的一套架构模式。通常来说，我们认为架构发展历史经历了这样一个过程：单体架构 -> SOA 面向服务架构 -> 微服务架构，

单体架构

在我们还是学生的年代，我们创建的绝大部分应用都属于单体应用。那个时候，我们几乎都是一个人在开发导师布置下来的各种实验。我们会把数据库连接、业务逻辑处理、展示逻辑等放在一起，甚至会在处理用户请求的地方直接连接数据库（多么美好的回忆啊 ^_^ ）。

后来，我们会学习到MVC架构以及由此衍生出来各种多层架构，由此便开启了应用的拆分之旅。多层架构的本质，是按照技术职责将应用做水平拆分，每一层解决的技术问题相对集中，层与层之间做单向依赖。这样做可以帮助我们更好的管理我们的代码，大大提升了后期的维护效率。但是，此时应用还是一个应用，部署时也是按照一个整体运行。我们看到的应用架构应该类似下面的样子：

在程序规模不大，开发人员很少的时候，下面的优点是非常显著的：

开发简单。单体应用的结构，天然决定了所有代码都集中在一起，开发者不需要在多个应用之间来回跳转来寻找其中的调用逻辑。
测试简单。所有代码都在一个应用里，测试人员可以很方便的做到端到端的测试（当然，很多时候测试人员就是开发者自己）。
部署简单。因为一个应用就是产品功能的全集，所以在部署的时候，只需要部署一款应用即可。即使是集群部署，也不会增加多少复杂度：只需要将应用部署多份即可。
开发迅速。上面的各种简单，带来的就是软件功能可以快速实现。很多时候，实现需求的速度是项目成功与否的决定性因素。

所以，在开发简单&独立的产品时，单体架构依然是第一优先选择。

如果故事可以一直这么简单就好了。

随着功能的持续增加、团队规模的不断扩大，我们很快就会发现单体应用的弊端：

应用膨胀。所有代码都在一个应用里，导致应用的代码量迅速上升，对于开发者来说，经常需要在海量的代码里找到自己需要维护的哪一行，这种体验往往是令人崩溃的。同时，对于IDE来说，一个应用内大量代码也会严重拖慢其运行效率。
团队合作冲突。这种冲突会体现在多个方面：开发阶段，很容易由于修改相同的代码导致代码冲突。部署阶段，又会因为“运行环境里跑的是谁的分支”而造成新的冲突。所有的这些冲突将会严重影响到团队的合作效率。
运行效率&稳定性。单体应用，由于逻辑都集中在一起，启动时需要完成所有的初始化工作；同时单一功能的问题也会因为运行在一个进程内，从而导致整个应用宕机。

单体架构原有的迅速、简单的优点，随着规模的扩大（功能、团队），会变得荡然无存。

为了能解决这些问题，我们自然而然就会想到分而治之的办法，即将原来的单体应用拆分开来。但是应用该怎么拆分？拆分后又会有哪些新的问题产生？如何解决这些新的问题？就留给下面的 SOA 架构来解答。

SOA 架构

SOA 是 Service-Oriented Architecture 的简写，直译为“面向服务的架构”，从命名上就可以看出“服务”是 SOA 架构里是非常重要的概念。SOA 的核心思想是“将系统的功能解构为一系列服务”：

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

与单体架构按照技术职责进行水平拆分不同，SOA 会按照业务领域对应用进行粗粒度的垂直拆分，至于拆分到什么程度，哪些领域可以放在一起等类似问题，可以参考一下康威定理。

应用从单体应用做了垂直拆分以后，就会变成一些相对独立的应用。此时，应用间的依赖、调用等相关问题自然而然的就会浮现出来。此时就需要下面这些技术方案来解决这些问题：

XML - 一种标记语言，用于以文档格式描述消息中的数据。
SOAP（Simple Object Access Protocol） - 在计算机网络上交换基于XML的消息的协议，通常是用HTTP。
WSDL（Web Services Description Language，Web服务描述语言） - 基于XML的描述语言，用于描述与服务交互所需的服务的公共接口，协议绑定，消息格式。
UDDI（Universal Description, Discovery, and Integration，是统一描述、发现和集成） - 基于XML的注册协议，用于发布WSDL并允许第三方发现这些服务。
ESB（Enterprise Service Bus, 企业服务总线）- 支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。

一个典型的 SOA 架构模式如下图：

SOA 看似解决了单体架构的所有问题，世界似乎都变得更加美好了 ^_^

但是....

SOA 并不完美，他也有很多问题的或者说是场景下的不适应。首先就是对 SOA 的解释缺乏统一标准，上文的引用的定义也只是众多解释中使用的较为通用的一种。甚至可以这么说：一千个人眼中，有一千种 SOA 。基于此，很多厂商便借用 SOA 的大旗来推广自己的产品和标准，这又进一步加剧了问题的严重性。

除此之外，SOA 还有很多其他的问题或不足：

高门槛。ESB 本身就是一套非常复杂的系统，通过 ESB 落地 SOA ，对开发人员的要求很高。甚至还会需要厂商参与；
厂商绑定。由于缺乏统一保准，不同厂商的解决方案之间很难做切换。
不适应云环境。在如今的互联网时代，速度就是一切。由此诞生了敏捷开发、持续集成等在不同节点提升业务上线速度的办法。但是方向是不一致的。
中心化。虽然应用本身实现了分布式与水平扩展，但是 ESB 却成了系统的中枢神经。

微服务架构

对于微服务架构，一直有一种说法，认为它是SOA架构的一种变体，或者是SOA的子集。关于这个问题，我们不去讨论他的对错（其实也没有对错之分），我们直接从这两者的区别入手来理解到底什么是微服务：

通信手段、数据等的不同只是表象，其本质区别还是由于两者诞生于不同历史时期，需要解决的问题域不同。SOA 解决的核心问题是复用，而微服务解决的核心问题是扩展。

关于什么是微服务，Martin Fowler 有如下的定义（更多 MartinFowler 关于微服务的内容，可以参考链接）：

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

这里提到几个重要的概念：

一套小服务
独立进程
轻量级通信协议
可独立部署
多语言&不同存储技术

这个定义对微服务做了一个比较具象化较为易于理解的描述，通常来说我们看到的微服务架构如下图所示：

但是事实上，在实际生产环境中，微服务的架构要考虑的问题远比上面的示意图复杂的多，主要包括但不限于如下问题：

通过服务实现组件化
根据业务组织系统
做产品而不是做项目
简单高效的通信协议
自动化基础设施
面向失败的设计
具备进化能力的设计

纵然有 Martin Fowler 这样的大神在前面引路，但是我们依然认为“微服务”不是一个被设计出来的架构，而是在不断尝试中总结出的一套适合在互联网行业使用的架构模式。以下的是微服务较为完整的架构图（出自微服务架构模式）

今天我们所说的“微服务”是一个庞大且复杂的概念集合，它既是一种架构模式，也是实现这种架构模式时所使用的技术方案的集合。

“微服务”不是银弹

微服务并不是一劳永逸的解决了所有的问题，相反的，如果不能正确的使用微服务，则有可能被微服务自身的限制拖入另一个泥潭：

分布式的代价。原本在单体应用中，很多简单的问题都会在分布式环境下被几何级的放大。例如分布式事务、分布式锁、远程调用等，不光要考虑如何实现他们，相关场景的异常处理也是必须要考虑到的问题。
协同代价。如果你经历过一个项目上线需要发布十几个应用，而这些应用又分别由多个团队在维护。你就能深刻的体会到协同是一件多么痛苦的事情了。
服务拆分需要很强的设计功力。微服务的各种优势，其中一个重要的基础是对服务领域的正确切分。如果使用了不合适的切分粒度，或者是错误的切分方法，都会让服务不能很好的实现高内聚低耦合的要求。