微服务架构的优点与不足

摘要: 微处理架构——处理复琐事物 　　许多公司，好比Amazon、eBay和NetFlix，经过采用微处理结构模式解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相链接的微服务。

微服务正在博客、社交媒体讨论组和会议演讲中得到愈来愈多的关注，在Gartner的2014 Hype Cycle上它的排名很是靠前。同时，软件社区中也有很多持怀疑论者，认为微服务不是什么新东西。Naysayers认为这就是SOA架构的从新包装。然 而，尽管存在着不一样的争论，微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供巨大的帮助。

首先咱们看看为何要使用微服务。

开发单体式应用

假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件，通过初步会议和需求分析，你可能会手动或者使用基于Rails、Spring Boot、Play或者Maven的生成器开始这个新项目，它的六边形架构是模块化的 ，架构图以下：

应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。

尽管也是模块化逻辑，可是最终它仍是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如，许多Java应用会被打包为WAR格 式，部署在Tomcat或者Jetty上，而另一些Java应用会被打包成自包含的JAR格式，一样，Rails和Node.js会被打包成层级目录。

这种应用开发风格很常见，由于IDE和其它工具都擅长开发一个简单应用，这类应用也很易于调试，只须要简单运行此应用，用Selenium连接 UI就能够完成端到端测试。单体式应用也易于部署，只须要把打包应用拷贝到服务器端，经过在负载均衡器后端运行多个拷贝就能够轻松实现应用扩展。在早期这 类应用运行的很好。

单体式应用的不足

不幸的是，这种简单方法却有很大的局限性。一个简单的应用会随着时间推移逐渐变大。在每次的sprint中， 开发团队都会面对新“故事”，而后开发许多新代码。几Year后，这个小而简单的应用会变成了一个巨大的怪物。这儿有一个例子，我最近和一个开发者讨论，他正在 写一个工具，用来分析他们一个拥有数百万行代码的应用中JAR文件之间的依赖关系。我很确信这个代码正是不少开发者通过多Year努力开发出来的一个怪物。

一旦你的应用变成一个又大又复杂的怪物，那开发团队确定很痛苦。敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以致于任何单个开 发者都不可能搞懂它。所以，修正bug和正确的添加新功能变的很是困难，而且很耗时。另外，团队士气也会走下坡路。若是代码难于理解，就不可能被正确的修 改。最终会走向巨大的、不可理解的泥潭。

单体式应用也会下降开发速度。应用越大，启动时间会越长。好比，最近的一个调查代表，有时候应用的启动时间竟然超过了12分钟。我还据说某些应用须要40分钟启动时间。若是开发者须要常常重启应用，那么大部分时间就要在等待中渡过，生产效率受到极大影响。

另外，复杂而巨大的单体式应用也不利于持续性开发。今天，SaaS应用常态就是天天会改变不少次，而这对于单体式应用模式很是困难。另外，这种变化带来的影响并无很好的被理解，因此不得不作不少手工测试。那么接下来，持续部署也会很艰难。

单体式应用在不一样模块发生资源冲突时，扩展将会很是困难。好比，一个模块完成一个CPU敏感逻辑，应该部署在AWS EC2 Compute Optimized instances，而另一个内存数据库模块更合适于EC2 Memory-optimized instances。然而，因为这些模块部署在一块儿，所以不得不在硬件选择上作一个妥协。

单体式应用另一个问题是可靠性。由于全部模块都运行在一个进程中，任何一个模块中的一个bug，好比内存泄露，将会有可能弄垮整个进程。除此以外，由于全部应用实例都是惟一的，这个bug将会影响到整个应用的可靠性。

最后，单体式应用使得采用新架构和语言很是困难。好比，设想你有两百万行采用XYZ框架写的代码。若是想改为ABC框架，不管是时间仍是成本都是很是昂贵的，即便ABC框架更好。所以，这是一个没法逾越的鸿沟。你不得不在最初选择面前低头。

总结一下：一开始你有一个很成功的关键业务应用，后来就变成了一个巨大的，没法理解的怪物。由于采用过期的，效率低的技术，使得雇佣有潜力的开发者很困难。应用没法扩展，可靠性很低，最终，敏捷性开发和部署变的没法完成。

那么如何应对呢？

微处理架构——处理复琐事物

许多公司，好比Amazon、eBay和NetFlix，经过采用微处理结构模式解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相链接的微服务。

一个微服务通常完成某个特定的功能，好比下单管理、客户管理等等。每个微服务都是微型六角形应用，都有本身的业务逻辑和适配器。一些微服务还 会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每个实例多是一个云VM或者是Docker容器。

好比，一个前面描述系统可能的分解以下：

每个应用功能区都使用微服务完成，另外，Web应用会被拆分红一系列简单的Web应用（好比一个对乘客，一个对出租车驾驶员）。这样的拆分对于不一样用户、设备和特殊应用场景部署都更容易。

每个后台服务开放一个REST API，许多服务自己也采用了其它服务提供的API。好比，驾驶员管理使用了告知驾驶员一个潜在需求的通知服务。UI服务激活其它服务来更新Web页面。全部服务都是采用异步的，基于消息的通信。微服务内部机制将会在后续系列中讨论。

一些REST API也对乘客和驾驶员采用的移动应用开放。这些应用并不直接访问后台服务，而是经过API Gateway来传递中间消息。API Gateway负责负载均衡、缓存、访问控制、API 计费监控等等任务，能够经过NGINX方便实现，后续文章将会介绍到API Gateway。

·微服务架构模式在上图中对应于表明可扩展Scale Cube的Y轴，这是一个在《The Art of Scalability》书中描述过的三维扩展模型。另外两个可扩展轴，X轴由负载均衡器后端运行的多个应用副本组成，Z轴是将需求路由到相关服务。

应用基本能够用以上三个维度来表示，Y轴表明将应用分解为微服务。运行时，X轴表明运行多个隐藏在负载均衡器以后的实例，提供吞吐能力。一些应用可能仍是用Z轴将服务分区。下面的图演示行程管理服务如何部署在运行于AWS EC2上的Docker上。

运行时，行程管理服务由多个服务实例构成。每个服务实例都是一个Docker容器。为了保证高可用，这些容器通常都运行在多个云VM上。服务实例前是 一层诸如NGINX的负载均衡器，他们负责在各个实例间分发请求。负载均衡器也同时处理其它请求，例如缓存、权限控制、API统计和监控。

这种微服务架构模式深入影响了应用和数据库之间的关系，不像传统多个服务共享一个数据库，微服务架构每一个服务都有本身的数据库。另外，这种思路也影响到了企业级数据模式。同时，这种模式意味着多份数据，可是，若是你想得到微服务带来的好处，每一个服务独有一个数据库是必须的，由于这种架构须要这种松耦合。下面的图演示示例应用数据库架构。

每种服务都有本身的数据库，另外，每种服务能够用更适合本身的数据库类型，也被称做多语言一致性架构。好比，驾驶员管理（发现哪一个驾驶员更靠近乘客），必须使用支持地理信息查询的数据库。

表面上看来，微服务架构模式有点像SOA，他们都由多个服务构成。可是，能够从另一个角度看此问题，微服务架构模式是一个不包含Web服务 （WS-）和ESB服务的SOA。微服务应用乐于采用简单轻量级协议，好比REST，而不是WS-，在微服务内部避免使用ESB以及ESB相似功能。微服 务架构模式也拒绝使用canonical schema等SOA概念。

微服务架构的好处

微服务架构模式有不少好处。首先，经过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的状况下，应用被分解为多个可管理的分支 或服务。每一个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由 此，单个服务很容易开发、理解和维护。

第二，这种架构使得每一个服务均可以有专门开发团队来开发。开发者能够自由选择开发技术，提供API服务。固然，许多公司试图避免混乱，只提供某 些技术选择。而后，这种自由意味着开发者不须要被迫使用某项目开始时采用的过期技术，他们能够选择如今的技术。甚至于，由于服务都是相对简单，即便用如今 技术重写之前代码也不是很困难的事情。

第三，微服务架构模式是每一个微服务独立的部署。开发者再也不须要协调其它服务部署对本服务的影响。这种改变能够加快部署速度。UI团队能够采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。

最后，微服务架构模式使得每一个服务独立扩展。你能够根据每一个服务的规模来部署知足需求的规模。甚至于，你可使用更适合于服务资源需求的硬件。 好比，你能够在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。

微服务架构的不足

Fred Brooks在30Year前写道，“there are no silver bullets”，像任何其它科技同样，微服务架构也有不足。其中一个跟他的名字相似，『微服务』强调了服务大小，实际上，有一些开发者鼓吹创建稍微大一 些的，10-100 LOC服务组。尽管小服务更乐于被采用，可是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用，实现敏捷开发和部署。

另一个主要的不足是，微服务应用是分布式系统，由此会带来固有的复杂性。开发者须要在RPC或者消息传递之间选择并完成进程间通信机制。更甚 于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。固然这并非什么难事，但相对于单体式应用中经过语言层级的方法或者进程调用，微 服务下这种技术显得更复杂一些。

另一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很广泛。这种交易对于单体式应用来讲很容易，由于只 有一个数据库。在微服务架构应用中，须要更新不一样服务所使用的不一样的数据库。使用分布式交易并不必定是好的选择，不只仅是由于CAP理论，还由于今天高扩 展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。

测试一个基于微服务架构的应用也是很复杂的任务。好比，采用流行的Spring Boot架构，对一个单体式web应用，测试它的REST API，是很容易的事情。反过来，一样的服务测试须要启动和它有关的全部服务（至少须要这些服务的stubs）。再重申一次，不能低估了采用微服务架构带 来的复杂性。

另一个挑战在于，微服务架构模式应用的改变将会波及多个服务。好比，假设你在完成一个案例，须要修改服务A、B、C，而A依赖B，B依赖C。 在单体式应用中，你只须要改变相关模块，整合变化，部署就行了。对比之下，微服务架构模式就须要考虑相关改变对不一样服务的影响。好比，你须要更新服务C， 而后是B，最后才是A，幸运的是，许多改变通常只影响一个服务，而须要协调多服务的改变不多。

部署一个微服务应用也很复杂，一个分布式应用只须要简单在复杂均衡器后面部署各自的服务器就行了。每一个应用实例是须要配置诸如数据库和消息中间件等基础服务。相对比，一个微服务应用通常由大批服务构成。例如，根据Adrian Cockcroft，NetFlix 有大约600个服务。每一个服务都有多个实例。这就形成许多须要配置、部署、扩展和监控的部分，除此以外，你还须要完成一个服务发现机制（后续文章中发 表），以用来发现与它通信服务的地址（包括服务器地址和端口）。传统的解决问题办法不能用于解决这么复杂的问题。接续而来，成功部署一个微服务应用须要开 发者有足够的控制部署方法，并高度自动化。

一种自动化方法是使用PaaS服务，例如Cloud Foundry。 PaaS给开发者提供一个部署和管理微服务的简单方法，它把全部这些问题都打包内置解决了。同时，配置PaaS的系统和网络专家能够采用最佳实践和策略来 简化这些问题。另一个自动部署微服务应用的方法是开发对于你来讲最基础的PaaS系统。一个典型的开始点是使用一个集群化方案，好比配合Docker使 用Mesos或者Kubernetes。后面的系列咱们会看看如何基于软件部署方法例如NGINX，能够方便的在微服务层面提供缓存、权限控制、API统 计和监控。

总结

构建复杂的应用真的是很是困难。单体式的架构更适合轻量级的简单应用。若是你用它来开发复杂应用，那真的会很糟糕。微服务架构模式能够用来构建复杂应用，固然，这种架构模型也有本身的缺点和挑战。

在后续的博客中，我会深刻探索微服务架构模式，并讨论诸如服务发现、服务部署选择和如何分解一个分布式应用为多个服务的策略。

愿意了解框架技术或者源码的朋友直接求求交流分享技术：2042849237

更多详细源码参考来源