微服务介绍 ：Introduction to Microservices

官网链接：

microservices

Microservices – Definition, Principles and Benefits

转自：微服务介绍

这是一篇由 Chris Richardson 撰写的客座文章。Chris 是 CloudFoundry.com 的创始人，这是一个早期的用于 Amazon EC2 的 Java PaaS (Platform-as-a-Service平台即服务)。他现在为大型组织提供咨询服务，帮助他们提升开发和部署应用的能力。他还在有规律地写关于微服务的博客，博客地址：http://microservices.io。

==============

目前，微服务得到较多的关注：论文，博文，社交媒体上的讨论，还有会议报告。他们处于期望膨胀期的顶峰，快速地向着登上 Gartner 趋势报告前进。同时，在软件社区还有一群怀疑论者，他们无视微服务，认为它没什么新意。反对派们声称，这种想法就是 SOA 的马甲。但是，不管是大肆宣传还是怀疑主义，微服务架构模式具有明显的好处——尤其谈到敏捷开发和复杂企业应用交付的时候。

这篇博文是一个关于设计、构建和部署微服务的七部系列的第一部分。你将会了解到微服务的方法和它与传统的单一架构模式的对比。这个系列将会详细说明微服务架构的众多元素。你将会了解到微服务架构模式的好处和缺点，对你的项目是否有意义，和怎样应用它。

现在，我们先看看为什么你应该考虑使用微服务。

构建整体应用

假设你想要构建一个全新的打车应用与 Uber 和 Hailo 竞争。经过了一些预备会议和需求收集之后，你将会手工创建一个新的工程，或者使用 Rails、Spring Boot、Play 或 Maven 这类工具生成一个。这个新应用将会有一个模块化的六角形架构，就像下图这样：

该应用的核心是服务模块、域对象模块和事件模块实现的业务逻辑。围绕在核心周围的是与外界交互的适配器。这些适配器包括数据库访问组件、生产和消费消息的消息传递组件、暴露 API 或实现 UI 的 web 组件。

尽管具有合乎逻辑的模块化架构，但是该应用做为整体打包部署。具体的样式依赖应用的语言和框架。例如许多Java应用打成WAR包，部署在Tomcat或Jetty这样的应用服务器。还有一些Java应用打成独立可执行的JAR包。类似的，Rails和Node.js应用以目录层次的形式打包。

写成这种形式的应用极其普遍。它们非常易于开发，因为我们的IDE和其他工具专注于构建一个单独的应用。这样的应用通常也易于测试。通过简单地运行应用就可以实现端到端的测试，使用Selenium就可以测试UI。整体应用也易于部署。你仅仅需要复制打包的应用到服务器。你也可以通过在负载均衡器后面运行多个副本的方式扩展应用。在项目的早期阶段，这种方式运作的很好。

走向整体地狱（Monolithic Hell）

很不幸，这种简单的方式有一个巨大的限制。成功的应用都会随着时间增大，最终变得巨大。在每一个冲刺（sprint），你的开发团队实现了许多用户故事，这当然意味着添加了许多行代码。经过几年之后，原本很小、很简单的应用将会长成可怕的庞然大物。举一个极端的例子，我最近与一个开发者进行了一次谈话，他写了一个工具分析他们数百万行代码的应用中的成千上万个JAR包的依赖。我很确定这样一个怪兽是由大量的开发者经过数年的共同努力才制造出来的。

一旦你的应用变成了一个复杂的庞然大物，你的开发团队就可能生活在痛苦之中。敏捷开发的任何尝试和交付将会举步维艰。该应用的一个主要问题是过度地复杂。它仅仅是太大了以至于任何一个开发者都不能完整地理解。因此正确地修复漏洞和实现新功能将会变得困难和耗时。更糟糕的是，这形成了一个恶性循环。如果基本代码难于理解，就很难做出正确的改动。那么最终就会成为一个可怕的、无法理解的大泥球。

应用程序的规模也会拖慢开发进度。应用程序的规模越大，启动的时间越长。例如在最近的调查中，开发者表示启动时间长达12分钟。我也道听途说过启动时间长达40分钟的应用程序。如果开发者不得不周期性重启应用服务，那么他们一天中很大一部分时间将浪费在等待上，他们的生产力将会受到影响。

巨大的、复杂的整体应用程序的另外一个问题是它是持续部署的障碍。目前，SaaS应用通常在一天之内会多次将改动推到生成环境。对于复杂的庞然大物，这极其难处理，因为你必须重新部署整个应用来更新程序的任何一小部分。我前面提到的冗长的启动时间也将产生不利的影响。而且因为改动的影响通常不能被充分的理解，那么你可能还必须做更广泛的手工测试。最终导致持续部署几乎是不可能的。

当不同的模块具有资源需求冲突的时候，整体应用程序也将难以扩展。例如，某个实现CPU密集型图像处理逻辑的模块非常适合部署在AWS EC2 Compute Optimized instances。另外某个内存数据库的模块最适合部署在 EC2 Memory-optimized instances。然后由于这些模块都得部署在一起，所以你不得不在硬件的选择上做出妥协。

整体应用程序的另外一个问题是可靠性。因为所有的模块都在同一进程内运行，所以任一模块的漏洞，比如内存泄露，将会影响整个进程。此外，因为应用程序的所有实例是一致的，所以这些漏洞将会影响整个应用的可用性。.

最后但并非不重要，整体应用程序使得采用新框架、新语言极其困难。举个例子来说，假设你有两百万行使用XYZ框架写的代码。那么使用新的ABC框架重写整个应用将会是极其昂贵的（无论是时间还是花费），即使新框架相当的好。因此对于采用新技术，整体应用程序具有巨大的障碍。当你开始新的项目的时候，你将非常纠结于选择哪种技术。

总而言之：你有一个已经长成可怕的庞然大物的，几乎没有开发者可以理解的，成功的业务关键应用。这个应用程序使用过时的、没有生产力的技术写成，这使得招聘优秀的开发者变得非常困难。这个应用程序难以扩展而且不可靠。因此，敏捷开发和应用交付是不可能的。

所以你能怎么办呢？

微服务 – 处理复杂性

许多组织，比如Amazon、eBay和Netflix，已经采用现在被称为微服务架构模式的方法解决了这个问题。其想法是将应用程序分割成更小的相互关联的服务，而不是构建单个可怕的整体应用程序。

一个服务通常实现一组独立的特性或功能，比如订单管理、客户管理等。每个微服务是一个具有六角形架构的迷你应用，其自己的六角形架构包含业务逻辑以及许多适配器。某些微服务将会暴露供其他微服务或者客户端使用的API。另外一些微服务可能实现web UI。在运行时，每个实例通常是一个云虚拟机或者一个Docker容器。

例如，前文所述的系统的一个可能的分解如下图所示：

应用的每个功能区域现在以微服务的方式实现。此外web应用程序分割成了一组更简单的web应用程序（一个面向乘客的，一个面向司机的）。这使得更容易为特定的用户、设备或特定的用例部署单独的服务。

每个后端服务暴露一套 REST API，大部分服务调用其他服务提供的 API。例如司机管理模块使用通知服务告知空闲的司机可能的订单。UI 服务调用其他服务来渲染 web 页面。服务也可能使用异步的、基于消息的通信方式。服务间通信将会在本系列后面的文章中详细讨论。

某些 REST API 是暴露给司机和乘客使用的移动 app 的。然后 app 不能直接访问后端服务，其间的通信是通过称为 API 网关的媒介传递的。API 网关负责负载均衡、缓存、访问控制、API 测量和监控，该模块可以使用 NGINX 有效的实现。本系列后面的文章将会讨论 API 网关。

微服务架构模式对应扩展立方体（Scale Cube）的 Y 轴扩展，扩展立方体是《The Art of Scalability》一书中描述可扩展性的 3D 模型。此外还有两个扩展维度，X 轴扩展表示在负载均衡器后面运行多个相同的应用程序副本，Z 轴扩展（数据分割）表示使用请求中的某个属性（例如数据表主键或用户 id）来路由请求到特定服务器。

应用通常综合使用三种扩展。Y 轴扩展分解应用程序到微服务，就像上图展示的那样。在运行时，为了吞吐量和可用性，X 轴扩展在负载均衡器后面运行多个服务的实例。某些应用也可能使用 Z 轴扩展分割服务。下图展示了如何使用 Docker 将订单管理服务部署在 AWS EC2 上。