微服务介绍（理论介绍）

作者 

Chris Richardson of Eventuate, Inc.  

May 19, 2015

本人翻译

微服务逐渐得到文章、博客、自媒体和会议的青睐，他们几乎达到发展的顶峰期。同时，一些社区认为微服务不是新鲜的概念，都是以前的概念。怀疑论者认为它仅仅是SOA概念的翻版。尽管有很多的否定者和怀疑论者，微服务架构尤其对于复杂的企业程序和灵活的开发组织具有着明显的益处。

创建单体程序

让我们想象一下你正在创建一个新的类似于UBER和Hailo的出租车新品牌。通过头脑风暴和前期信息的收集，你开始手动创建一个工程或者通过Rails, Spring Boot, Play, or Maven。这个程序具有六边形的架构，如下图所示：

 

这个程序的核心是业务逻辑服务，包括服务定义、域对象和事件等。四周的是与外界的接口适配，例如数据库操作层、消息队列、Web调用适配、UI调用适配和Rest调用适配等。

虽然程序划分逻辑块，程序被物理上打包和部署为一个产品。具体的程序依赖于程序的语言和框架结构。例如，Java被打包为War包，不属于Tomcat或者Jetty的容器中。类似的, Rails and Node.js被打包在一个树状结构的文件夹里。

这种样式的程序极其普通。因为都在一个集成开发工具里，所以他们开发和部署及其简单。这种程序也易于测试，因为极易创建从前端到后端的测试链条。单体程序易于部署，你仅仅需要拷贝部署包到相应服务器。你可以通过负载均衡实现程序的横向部署。在程序创建的前期，它运转一切良好。

 

逐渐走向单体应用地狱

不幸的是，这种应用具有着巨大的限制。成功的产品随着时间的应用，逐渐变得越来越大。每一次小功能的改进，研发人员都会加入一些新的代码。几年之后，小的程序将变成巨大的单体应用。我相信运行这个巨大的怪物将会耗费研发人员巨大的精力。

一旦你的程序成为了巨大、复杂的单体应用，你的研发人员将会变得非常难受。灵活的的开发和交付的想法将会变得没有希望。一个主要的问题是程序变得过于复杂。这个问题很好理解，因为一个人很难理解复杂的项目。因此，修复Bug和开发新功能将会变得困难和耗时。另外，这会导致形成恶性循环。如果代码很难理解，很难做出正确的修改。你将会进入一个巨大的、难于理解的巨大怪物的泥潭。

应用程序的大小将会降低研发效率。程序越大，启动时间越长。例如，最近的一份报告显示启动时间仅仅12分钟。我听说过启动需要40分钟的例子。如果开发者需要经常重启服务，那么会有大量的时间浪费与程序重启，将会导致开发效率降低。

大程序的另外一个障碍是持续的部署问题。现在一个Saas程序一天需要修改部署几次。如果对于大程序这将会变得困难，因为一点小的变动将会发布整个程序。再加之之前的启动问题，将会加剧问题。.（实际上，单体应用还有一个具体的问题便是耦合性，发布任何一点更新，可能都会对原有的问题产生影响。）

当不同模块需求资源不同时，程序的横向扩展将会变得艰难。例如，一部分程序可能需要CPU密集型部署，一部分程序需要IO密集型部署。由于所有的模块集中在一起，导致个性化的部署方案将难于推进。

另外，单体应用的问题便是可用性。因为所有的模块运行于一个进程中，任何一个模块的Bug，像程序泄露，都会导致整个进程的崩溃。因为所有程序部署的实例都一样，可能整个程序都会挂掉。

不仅如此，单体应用使得吸收新的框架和语言非常困难。因为所有的单体应用使用的语言都是一致的，如果用其他语言开发，则会导致整个框架的重新返工。

总结：如果你有一个关键程序采用单体架构，并且用过时、低效的开发语言编写，这将会使得研发人员开发非常困难。使得灵活应对和快速交付变得困难。

针对此，你能做什么呢？

 

微服务--处理复杂度

许多组织，像Amazon, eBay, and Netflix，通过微服务架构已经成功的解决了这类问题。不是通过构建一个巨大的程序，而是将程序分解为一些列小的、内部相互沟通的程序。

一个服务能够负责不同的职能或者功能，像订单管理、客户管理等。每个微服务都是一个小的程序，它具有着六边形的业务逻辑和适配器。一些微服务将会暴漏一些供其他微服务或者客户端调用的API。一些微服务可能执行Web UI操作。运行时，任何的微服务都是一个云虚拟机或者一个Dock容器。

例如，一个协同的架构图如下所示：

 

不同应用程序的服务运行于他们自己的微服务里面。另外，web程序被分解为几个程序组合（像客户使用一个；司机使用一个）。这使得它可以按照不同的用户部署不同的程序。

任何一个后端服务暴漏一个REST API接口，大部分服务消费其他服务的接口。例如司机管理服务用消息服务通知司机一个潜在的订单。UI服务调用其他服务的数据刷新页面数据。服务可能采用异步、消息队列机制通信。

移动服务会调用司机服务和乘客服务。应用程序将不会直接调用后端服务。相反，服务的调用将会被通过API网管中转。API网管负责负载均衡、缓存、权限控制、监控和接口测量。通常API网管采用Nginx实现。

 

 

 

微服务架构通过伸缩立方体实现伸缩，X轴代表单个服务的水平扩展，例如通过负载均衡实现；Y轴通过不同的功能将微服务划分为不同的业务主体；Z轴是指进行数据的分区，也就是说微服务赞同具有独立的运行环境、操作数据。下图为部署到Dock中的一个架构图

 

运行的时候，订单管理服务包含多个微服务。每个服务是一个Dock容器。为了高可用，容器运行于多个云虚拟机上。在服务实例之间是Ngnix负载均衡器。负载均衡器也会处理其他的功能，像缓存、控制权限、API测量和监控。

微服务架构深深地影响了程序和数据库之间的关系。不再是多个程序共享一个数据库，而是一个微服务享有一个数据库。另外，这个观点影响了企业数据的架构模型。它经常存在于一些数据的备份。一个服务一个数据库的模式是有必要的，因为它降低了不同服务之间的耦合性。下图展示了微服务的数据库架构：

 

每个微服务都有自己的数据库，另外，每个服务可以根据自己的需要选择最合适的数据库，因此也称之为多语言架构。例如，司机管理服务需要查找离乘客最近的司机，因此需要一个高效的地理位置数据库。

表面上，微服务类似于SOA架构。两者的相同点是都包含许多服务。微服务不像SOA通过WS和ESB通信，而是通过轻量级的REST服务通信。

微服务的好处

微服务架构有许多好处。第一，它降低问题的复杂度。它将一个巨大的单体应用分解为不同的微服务。整体的功能没有改变，但是分解为可管理的不同应用。每个服务都有明确的边界，方便RPC或者消息队列调用。微服务使得巨大的单体应用划分为不同的代码块，使得易于理解和维护。

第二，单个的服务能够使得每个小组专注于某个功能模块。开发者可以根据需要选择不同的技术，并且关注与接口契约。当然，大部分的组织避免完全的技术选择自由。这种自由意味着开发者不用在选择项目开始时过时的技术语言开发。

第三，微服务能够使每个服务独立部署。开发者不用再协调服务周边的功能。这种功能能够使得开发效率和测试效率大大提高。

最后，微服务能够使得每个服务独立的伸缩。每个服务能够根据不同服务在容量、可用性的限制扩展微服务。另外，你能够采用最佳的硬件配置匹配服务。

微服务的缺陷

Fred Brooks已经书写了30年，没有万能的银弹。像每种技术，微服务存在缺陷。首先微服务就像他的名字，开发团队会关注与程序的大小。实际上微服务的目的是将程序分解为灵活和快速交付的产品，而不应该是以具体的产品大小为目的。

另外一个缺陷是来自于拆分后的分布式复杂性。微服务需要实现基于消息或者RPC的线程交流机制。另外，它必须处理传输掉包或者不可达导致的请求失败问题。虽然这些都不是一些高深的科学，但是这比进程内通信的单体应用复杂的多。

另外一个挑战是数据库的分区。业务交易同时更新许多服务在显示业务中非常正常。这些交易在单体应用中非常正常，因为都是基于一个数据库。在微服务里面，你需要更新许多不同服务的数据库。根据CAP理论，是不存在完整的分布式事务理论。他们都不被现在的NOSQL数据库或者消息服务器支持。你只能采用最终一致性事务理论解决此类问题。

测试微服务也将会较为复杂。例如如果在单体应用中写一个服务，并进行测试可能非常简单。但是在微服务中，需要首先启动其相关的服务，然后才能够测试此服务。这不是高深的科学，但是理解这样做的复杂性非常有必要。

另外一个挑战是微服务的更新可能涉及多个服务。例如，一个更新服务涉及A,B和C服务，在单体应用中直接一块更新和部署即可。但是在微服务中，首先应该更新C服务，如果其没有问题，再更新B服务，最后更新A服务。必须做好不同服务之间的协调和更新服务。

部署微服务也较为复杂。一个单体应用部署相同的服务与负载均衡器之后。每个服务实例需要部署基础服务的地址（像数据库和消息队列）。微服务的部署包括大量的服务，例如hailo需要160台服务，Netflix需要600台服务器。每个服务具有多个运行实例。他们有多个部分需要配置、部署、伸缩和监控。另外，你也需要实现一个服务发现机制（让相互通信的服务之间能够自动发现）。传统的手动操作已经不能够满足这种级别的复杂性。因此，一个成功的服务部署需要更高级别的研发和自动化水平。

一个自动化的方案是采用云部署。一个Pass的服务能够为用户提供简单的部署和管理途径。它能够使得他们从获得和配置IT资源中独立出来。同时，系统和网络专家会按照最佳的实践和企业策略配置Paas平台。另外一种方式是开发自己的Pass平台，一种经典的集群策略是采用Kubernetes, 配合Docker技术。

总结

创建一个程序存在其固有的负载型。单体的应用适合程序创建的初期，不适合大型负责的工程。虽然微服务也存在缺陷和挑战，但是在复杂的程序面前还是较好的一种解决方案。