微服务架构 | 微服务是什么？
▲图/ 只怪这猫咪太可爱了
hi guys，这里是桑小榆。
上篇我们已经过渡完了软件架构的发展历程。在面临大型应用，超大型应用以及承载海量用户时，不得不考虑架构微服务，这也是如今火热的原因之一。接下来就是咱们一起认识微服务了。不知道你们是不是同样有一个困惑，到底什么是微服务？能从“微”来衡量吗？微服务到底体现在哪？
▲图/ 微服务专栏将对上图策略逐一探讨，欢迎订阅
很遗憾的是，微服务这个叫法本身暗示和强调了尺寸，也就是暗示了微服务的大小，但实际上微服务架构对构建的服务实例并没有大小方面得要求，难以衡量它得颗粒度程度。
什么是微服务
到底什么是微服务？微服务，也称为微服务架构，是一种架构风格，它将应用程序构建为服务的集合，这些服务具备：
-
高度可维护和可测试。
-
松耦合。
-
围绕业务能力组织。
-
由一个小团队拥有。
微服务架构支持快速、频繁和可靠地交付大型、复杂的应用程序。它还使组织使用任意的技术堆栈。
我们也可以借助《可伸缩的艺术》来描述微服务架构的概念，或许会给你有一些启发。
X轴扩展，在多个实例之间实现请求的负载均衡，相当于将一个服务拷贝多个服务部署。
Z轴扩展，根据请求的属性路由策略来分配请求对应的服务，和X轴扩展不同，这里的每个实例仅负责数据的一个子集，例如通过用户所在区域来划分，分为华东地区，华北地区，华南地区的用户。
Y轴扩展，根据功能把应用拆分为服务，X轴和Y轴提升了应用的吞吐量和可用性，然而这两种方式都没有解决日益增长的开发问题和应用复杂性。Y扩展就是把一个单体应用分成了一组服务。
通过上面多维图的示例，我们能够清晰地看到微服务架构体系下，每一个服务都是高度独立，五脏俱全，各自应付各自的功能。
因此，我们可以采用著名架构师，克里斯·理查德 对于微服务的概括定义：把应用程序功能性分解为一组服务的架构风格。这句话依然没有规模性的描述，仅仅只是功能性的分解为一组服务，每一个服务都是由一组专注的、内聚的功能职责完成。
微服务架构作为模块化的一种形式。模块化是开发大型、复杂的应用程序的基础，微服务便是作为模块化的单元。是的，微服务更加适合大型应用的开发，据我了解很多企业的应用规模其实并不大，他们更多在Y轴上进行功能性拆分，甚至还没到X轴上应用更别说Z轴的应用扩展。
微服务架构的一个关键特性就是每一个服务之间都是松耦合的，它们仅仅通过api通讯。要实现这种松耦合的方式之一，是每个服务拥有自己的私有数据库，这一点我们可以看到面向服务架构（SOA）使用的是一个共享的数据库，拆分的每个服务都是调用这一个数据库。
这里，我们也可以通过一个大型应用的架构图来看看微服务架构的骨架。
▲图/ 某大型餐饮系统架构
这里我们可以看到，每个服务以及API都是非常清晰的定义，且每个服务可以独立开发、测试、部署和扩展。该架构也在保持模块化方面做的很好，开发人员无法绕过服务的API并访问其内部组件。
微服务与SOA异同
另外，我们也可以和上篇文章的面向服务架构（SOA）做个比较。当中也有不少的伙伴其实认为微服务架构就是SOA架构，百度百科对微服务的注解，也有声明是SOA架构的一种变体。确实在某些层面上有些相似，相似的架构风格，对拆分的多组服务按照一定的方式组成一个大应用。
但是，如果仔细深究微服务，能够看到微服务和SOA服务之间的明显差异。
|
SOA |
微服务 |
|
| 服务间通讯 |
智能管道，例如企业服务总线（ESB），往往采用轻量级协议，例如SOAP或者其他WS*标准。 |
使用哑管道，即无状态，例如消息代理，或者服务之间点对点通信，使用例如REST或者gRPC类的轻量级协议。 |
| 数据管理 |
全局数据模型并共享数据库。 |
每个服务都有自己的数据模型和数据库。 |
| 典型服务规模 |
较大的单体应用 |
较小的服务。 |
微服务的好处
选择微服务架构之后，我们能够显著看到这种架构模式给我们带来的好处。
使大型的复杂应用程序可以持续交付和持续部署。因为它拥有持续交付和持续部署所需要的可测试性，可部署性，开发团队能够自主且松散耦合。这会让我们的开发速度变得更加快。
每个服务相对较小并容易维护。由于服务较小，在我们的IDE记载不会有负担，同时调试和新人接触单个服务业务也更加方便。
服务可独立扩展。在扩展方面，我们可以参照上图的X，Y，Z轴来看，他们的扩展都是可伸缩的。
更好的容错性。独立的服务也更好地提供隔离，并不会因为一点的改动或者error而导致别的服务也受影响。
更容易实验和采纳新技术。这种服务架构可以很好地消除技术栈所带来的长期依赖。完全可以采用别的技术栈对其重构。
微服务的弊端
当然，任何技术都存在它的弊端行，没有弊端就没有新型技术的演进。
服务的拆分和定义是一种挑战。拆分服务是一项具备艺术的行为，因其本身就没有一个具体、良好的定义的模板或者算法来协助我们的拆分工作。
分布式系统带来的各种复杂性。采用这项模式之后，我们依然需要考虑它的复杂性，比如测试、事务、部署模式、横切关注点、通讯、网关、服务发现、可靠性、安全，可观察性（日志、审计、跟踪，健康检查）等等一系列额外的任务需要做。
当部署跨越多个服务的功能时需要谨慎地协调更多开发团队。使用微服务架构的另一项挑战就是当部署跨越多个服务的功能时需要谨慎地协调更多开发团队来配合。
开发者需要思考到底应该在应用的什么阶段使用微服务架构。我们必须要先知道应用在何阶段使用微服务架构，又在和情况下需要采用其他的策略来填补微服务带来的问题。
微服服的策略选择
好了，这一篇章的分享，相信我们对于微服务架构模式的概念有一个很好的掌握了。
它使得我们在面对业务开发软件应用时，我们一般必须做出一个决策，是采用单体架构模式还是微服务架构模式。如果我们采用微服务架构模式，我们将需要选择诸多其他模式来处理我们的决策的后果。
第一大难题就是我们应当如何去分解服务，是按照业务能力分解、子域、独立服务，又或者是按照团队的服务？
其次是数据管理，是采用每个服务拥有独立数据库，还是共享数据库，又或者其他Saga、API组成、CQRS、领域事件，事件朔源。
其余策略则是测试、事务、部署模式、横切关注点、通讯、网关、服务发现、可靠性、安全，可观察性（日志、审计、跟踪，健康检查）等等。
以上都是我们需要选择的一系列决策来完善我们的决策。当然这将在后续我们一起探讨。
以上图文均为亿图工具自己手绘，忽略丑吧~
如果喜欢文章的话，点个👍也是莫大的鼓励。
