学习笔记：什么是微服务？

　　现在微服务倍受关注：文章、博客、社交媒体讨论和会议演讲。微服务正在迅速朝着加德纳技术成熟度曲线（Gartner Hype cycle）的高峰前进。与此同时，也有持怀疑态度的软件社区人员认为微服务没什么新鲜可言。反对者声称它的思想只是面向服务架构（SOA）的重塑。然而，不管是炒做仍是怀疑，不能否认，微服务架构模式具备很是明显的优点 — 特别是在实施敏捷开发和复杂的企业应用交付方面。

　　咱们先来看看为何要考虑使用微服务。

 

构建单体应用

　　咱们假设，您开始开发一个打车应用，打算与 Uber 和 Hailo 竞争。通过初步交流和需求收集，您开始手动或者使用相似 Rails、Spring Boot、Play 或者 Maven 等平台来生成一个新项目。

　　该新应用是一个模块化的六边形架构，如图 1-1 所示：

图 1-一、一个简单的打车应用

　　该应用的核心是由模块实现的业务逻辑，它定义了服务、领域对象和事件。围绕核心的是与外部世界接口对接的适配器。适配器示例包括数据库访问组件、生产和消费消息的消息组件和暴露了 API 或实现了一个 UI 的 web 组件。

　　尽管有一个逻辑模块化架构，但应用程序被做为一个单体进行打包和部署。实际格式取决于应用程序的语言和框架。例如，许多 Java 应用程序被打包成 WAR 文件部署在如 Tomcat 或者 Jetty 之类的应用服务器上。其余 Java 应用程序被打包成自包含（self-contained）的可执行 JAR。相似地，Rails 和 Node.js 应用程序被打包为有目录层次的结构。

　　以这种风格编写的应用是很常见的。他们很容易开发，由于咱们的 IDE 和其余工具就是专一于构建单体应用。这些应用程序也很容易测试，您能够经过简单地启动并使用如 Selenium 测试包来测试 UI 以轻松地实现端到端（end-to-end）测试。单体应用一样易于部署，你只需拷贝打包好的应用程序到服务器上。您还能够经过运行多个副本和结合负载均衡器来扩展应用。在项目的早期阶段，它能够良好运做。

 

走向单体地狱

　　不幸的是，这种简单的方法有很大的局限性。成功的应用有一个趋势，随着时间推移而变得愈来愈臃肿。您的开发团队在每一个冲刺阶段都要实现更多的用户需求，这意味着须要添加许多行代码。几年以后，小而简单的应用将会逐渐成长成一个庞大的单体。为了给出一个极端示例，我最近和一位开发者作了交谈，他正在编写一个工具，该工具用于从他们的数百万行代码（lines of code，LOC）应用中分析出数千个 JAR 之间的依赖。我相信这是大量开发者在多年齐心合力下创造出了这样的野兽。

　　一旦您的应用程序成为了一个庞大、复杂的单体，您的开发组织可能会陷入了一个痛苦的境地，敏捷开发和交付的任何一次尝试都将原地徘徊。一个主要问题是应用程序实在很是复杂，其对于任何一个开发人员来讲显得过于庞大，这是能够理解的。最终，正确修复 bug 和实现新功能变得很是困难而耗时。此外，这种趋势就像是往下的螺旋。若是基本代码都使人难以理解，那么改变也不会变得正确，您最终获得的将是一个巨大且难以想象的大泥球。

　　应用程序的规模也将减缓发展。应用程序越大，启动时间越长。我调查过开发者们的单体应用的大小和性能，一些报告的启动时间为 12 分钟。我也据说过应用程序启动须要 40 分钟以上的怪事。若是开发人员常常要重启应用服务器，那么很大一部分时间都是在等待中度过，他们的生产力将受到限制。

　　另外一个大问题是，复杂的单体应用自己就是持续部署的障碍。现在，SaaS 应用发展到了能够天天屡次将变动推送到生产环境。这对于复杂的单体来讲很是困难，由于您须要从新部署整个应用程序才能更新其中任何一部分。联想到我以前提到的漫长启动时间，这也不会是什么好事。此外，因变动所产生的影响一般不是很明确，您极可能须要作大量的手工测试。所以，持续部署是不可能作到的。当不一样模块存在资源需求冲突时，单体应用可能难以扩展。例如，一个模块可能会执行 CPU 密集型图像处理逻辑，理想状况下是部署在 Amazon EC2 Compute Optimized 实例中。另外一个模块多是一个内存数据库，最适合部署到 EC2 Memory-optimized 实例。然而，因为这些模块被部署在一块儿，您必须在硬件选择上作出妥协。

　　单体应用的另外一个问题是可靠性。由于全部模块都运行在同一进程中。任何模块的一个 bug，好比内存泄漏，可能会拖垮整个进程。此外，因为应用程序的全部实例都是相同的，该错误将影响到整个应用的可用性。

　　最后但一样重要，单体应用使得采用新框架和语言变得很是困难。例如，咱们假设您有 200 万行代码使用了 XYZ 框架编写。若是使用较新的 ABC 框架来重写整个应用，这将很是昂贵（在时间和成本方面），即便框架很是好。所以，这对于采用新技术是一个很是大的障碍。在项目开始时，您不管选择何种新技术都会感到困扰。

　　总结一下：您有一个成功的关键业务应用程序，它已经发展成为一个只有少数开发人员（若是有的话）可以理解的巨大单体。它使用了过期、非生产性技术编写，这使得招聘优秀开发人员变得很是困难。应用程序变得难以扩展，不可靠。所以敏捷开发和应用交付是不可能的。

　　那么您能作些什么呢？

 

微服务 — 解决复杂问题

　　许多如 Amazon、eBay 和 Netflix 这样的组织，已经采用如今所谓的微服务架构模式解决了这个问题，而不是构建一个臃肿的单体应用。它的思路是将应用程序分解成一套较小的互连服务。一个服务一般实现了一组不一样的特性或功能，例如订单管理、客户管理等。每个微服务都是一个迷你应用，它本身的六边形架构包括了业务逻辑以及多个适配器。一些微服务会暴露一个供其余微服务或应用客户端消费的 API。其余微服务可能实现了一个 web UI。在运行时，每一个实例一般是一个云虚拟机（virtual machine，VM）或者一个 Docker 容器。例如，前面描述的系统可能分解成如图 1-2 所示：

图 1-二、一个单体应用分解成微服务

　　应用程序的每一个功能区域如今都由本身的微服务实现。此外，Web 应用程序被划分为一组更简单的应用。例如，以咱们的出租车为例，一个是乘客的应用，一个是司机的应用。这使得它更容易地为特定的用户、司机、设备或者专门的用例部署不一样的场景。每一个后端服务暴露一个 REST API，大部分服务消费的 API 由其余服务提供。例如，Driver Management 使用了 Notification 服务器来通知可用司机一个可选路程。UI 服务调用了其余服务来渲染页面。服务也可使用异步、基于消息的通讯。本电子书后面将会更加详细介绍服务间通讯。

　　一些 REST API 也暴露给移动端应用以供司机和乘客使用。然而，应用不能直接访问后端服务。相反，他们之间的通讯是由一个称为 API 网关（API Gateway）的中介负责。API 网关负责负载均衡、缓存、访问控制、API 计量和监控，能够经过使用 NGINX 来实现。第二章将详细讨论 API 网关。

图 1-三、开发和交付中的伸缩立方（Scale Cube）

　　微服务架构模式至关于此伸缩立方的 Y 轴坐标，此立方是一个来自《架构即将来》的三维伸缩模型。另外两个坐标轴是由运行多个相同应用程序副本的负载均衡器组成的 X 轴坐标和 Z 轴坐标（或数据分区），其中请求的属性（例如，一行记录的主键或者客户标识）用于将请求路由到特定的服务器。应用程序一般将这三种类型的坐标方式结合一块儿使用。Y 轴坐标将应用分解成微服务，如图 1-2 所示。

　　在运行时，X 坐标轴上运行着服务的多个实例，每一个服务配合负载均衡器以知足吞吐量和可用性。某些应用程序也有可能使用 Z 坐标轴来进行分区服务。图 1-4 展现了如何用 Docker 将 Trip Management 服务部署到 Amazon EC2 上运行。

图 1-四、使用 Docker 部署 Trip Management 服务

　　在运行时，Trip Management 服务由多个服务实例组成，每一个服务实例是一个 Docker 容器。为了实现高可用，容器是在多个云虚拟机上运行的。服务实例以前是一个相似 NGINX 的负载均衡器，用于跨实例分发请求。负载均衡器也能够处理其余问题，如缓存、访问控制、API 度量和监控。

　　微服务架构模式明显影响到了应用程序与数据库之间的关系，与其余共享单个数据库模式（schema）服务有所不一样，其每个服务都有本身的数据库模式。一方面，这种作法与企业级数据库数据模型的想法相背，此外，它常常致使部分数据冗余。然而，若是您想从微服务中受益，每个服务都应该有本身的数据库模式，由于它能实现松耦合。图 1-5 展现了数据库架构示例应用程序。

　　每一个服务都拥有各自的数据库。并且，服务可使用一种最适合其需求、号称多语言持久架构（polyglot persistence architecture）的数据库。例如，Driver Management，要找到与潜在乘客接近的司机，就必须使用支持高效地理查询的数据库。

图 1-五、打车应用的数据库架构

　　从表面上看，微服务架构模式相似于 SOA。微服务是由一组服务组成。然而，换另外一种方式去思考微服务架构模式，它是没有商业化的 SOA，没有集成 Web 服务规范（WS-*）和企业服务总线（Enterprise Service Bus，ESB）。基于微服务的应用支持更简单、轻量级的协议，例如，REST，而不是 WS-*。他们也尽可能避免使用 ESB，而是实现微服务自己具备相似 ESB 的功能。微服务架构也拒绝了 SOA 的其余部分，例如，数据访问规范模式概念。

 

微服务的优势

　　微服务架构模式有许多很是好的地方。

　　第一，它解决了复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务。虽然功能数量不变，可是应用程序已经被分解成可管理的块或者服务。每一个服务都有一个明肯定义边界的方式，如远程过程调用（RPC）驱动或消息驱动 API。微服务架构模式强制必定程度的模块化，实际上，使用单体代码来实现是极其困难的。所以，使用微服务架构模式，个体服务能被更快地开发，并更容易理解与维护。

　　第二，这种架构使得每一个服务均可以由一个团队独立专一开发。开发者能够自由选择任何符合服务 API 契约的技术。固然，更多的组织是但愿经过技术选型限制来避免彻底混乱的状态。然而，这种自由意味着开发人员再也不有可能在这种自由的新项目开始时使用过期的技术。当编写一个新服务时，他们能够选择当前的技术。此外，因为服务较小，使用当前技术重写旧服务将变得更加可行。

　　第三，微服务架构模式能够实现每一个微服务独立部署。开发人员根本不须要去协调部署本地变动到服务。这些变动一经测试便可当即部署。好比，UI 团队能够执行 A|B 测试，并快速迭代 UI 变动。微服务架构模式使得持续部署成为可能。

　　最后，微服务架构模式使得每一个服务可以独立扩展。您能够仅部署知足每一个服务的容量和可用性约束的实例数目。此外，您可使用与服务资源要求最匹配的硬件。例如，您能够在 EC2 Compute Optimized 实例上部署一个 CPU 密集型图像处理服务，而且在 EC2 Memory-optimized 实例上部署一个内存数据库服务。

 

微服务的缺点

　　就像 Fred Brooks 大约在 30 年前写的《人月神话》中说的，没有银弹。与其余技术同样，微服务架构模式也存在着缺点。

　　其中一个缺点就是名称自己。微服务这个术语的重点过多偏向于服务的规模。事实上，有些开发者主张构建极细粒度的 10 至 100 LOC（代码行） 服务，虽然这对于小型服务可能比较好，但重要的是要记住，小型服务只是一种手段，而不是主要目标。微服务的目标在于充分分解应用程序以方便应用敏捷开发和部署。

　　微服务另外一个主要缺点是因为微服务是一个分布式系统，其使得总体变得复杂。开发者须要选择和实现基于消息或者 RPC 的进程间通讯机制。此外，因为目标请求可能很慢或者不可用，他们必需要编写代码来处理局部故障。虽然这些并非很复杂、高深，但模块间经过语言级方法/过程调用相互调用，这比单体应用要复杂得多。

　　微服务的另外一个挑战是分区数据库架构。更新多个业务实体的业务事务是至关广泛的。这些事务在单体应用中的实现显得微不足道，由于单体只存在一个单独的数据库。在基于微服务的应用程序中，您须要更新不一样服务所用的数据库。一般不会选择分布式事务，不只仅是由于 CAP 定理。他们根本不支持现在高度可扩展的 NoSQL 数据库和消息代理。您最后不得不使用基于最终一致性的方法，这对于开发人员来讲更具挑战性。

　　测试微服务应用程序也很复杂。例如，使用现代框架如 Spring Boot，只须要编写一个测试类来启动一个单体 web 应用程序并测试其 REST API。相比之下，一个相似的测试类对于微服务来讲须要启动该服务及其所依赖的全部服务，或者至少为这些服务配置存根。再次声明，虽然这不是一件高深的事情，但不要低估了这样作的复杂性。

　　微服务架构模式的另外一个主要挑战是实现了跨越多服务变动。例如，咱们假设您正在实现一个变动服务 A、服务 B 和 服务 C 的需求，其中 A 依赖于 B，且 B 依赖于 C。在单体应用程序中，您能够简单地修改相应的模块、整合变动并一次性部署他们。相反，在微服务中您须要仔细规划和协调出现的变动至每一个服务。例如，您须要更新服务 C，而后更新服务 B，最后更新服务 A。幸运的是，大多数变动只会影响一个服务，须要协调的多服务变动相对较少。

　　部署基于微服务的应用程序也是至关复杂的。一个单体应用能够很容易地部署到基于传统负载均衡器的一组相同服务器上。每一个应用程序实例都配置有基础设施服务的位置（主机和端口），好比数据库和消息代理。相比之下，微服务应用程序一般由大量的服务组成。例如，据 Adrian Cockcroft 了解到，Hailo 拥有 160 个不一样的服务，Netflix 拥有的服务超过 600 个。

　　每一个服务都有多个运行时实例。还有更多的移动部件须要配置、部署、扩展和监控。此外，您还须要实现服务发现机制，使得服务可以发现须要与之通讯的任何其余服务的位置（主机和端口）。比较传统麻烦的基于票据（ticket-based）和手动的操做方式没法扩展到如此复杂程度。所以，要成功部署微服务应用程序，须要求开发人员能高度控制部署方式和高度自动化。

　　一种自动化方式是使用现成的平台即服务（PaaS），如 Cloud Foundry。PaaS 为开发人员提供了一种简单的方式来部署和管理他们的微服务。它让开发人员避开了诸如采购和配置 IT 资源等烦恼。同时，配置 PaaS 的系统人员和网络专业人员能够确保达到最佳实践以落实公司策略。自动化微服务部署的另外一个方式是开发本身的 PaaS。一个广泛的起点是使用集群方案，如 Kubernetes，与 Docker 等容器技术相结合。

 

总结

　　构建复杂的微服务应用程序本质上是困难的。单体架构模式只适用于简单、轻量级的应用程序，若是您使用它来构建复杂应用，您最终会陷入痛苦的境地。微服务架构模式是复杂、持续发展应用的一个更好的选择。尽管它存在着缺点和实现挑战。

 

---

个人笔记

　　1. 关于高可用、高并发、高性能：属于分布式框架设计须要考虑的点。高可用：保证系统一直可用；高并发：保证系统能被同时并行处理不少请求；高性能：指程序处理速度很是快，所占内存少，cpu占用率低。

 

　　2. 关于微服务架构的数据库：在微服务架构中，每个服务有本身的数据库，因此咱们单个数据库中部分数据的外键取消了，致使不一样数据库中的数据相互使用时必须重复数据，致使部分数据冗余。

 

　　3.三个名词：IaaS、PaaS、SaaS 即云计算的三种服务模式

• SaaS：Software-as-a-Service（软件即服务）提供给客户的服务是运营商运行在云计算基础设施上的应用程序，用户能够在各类设备上经过客户端界面访问，如浏览器。消费者不须要管理或控制任何云计算基础设施，包括网络、服务器、操做系统、存储等等；
• PaaS：Platform-as-a-Service（平台即服务）提供给消费者的服务是把客户采用提供的开发语言和工具（例如Java，python, .Net等）开发的或收购的应用程序部署到供应商的云计算基础设施上去。
• IaaS： Infrastructure-as-a-Service（基础设施即服务）提供给消费者的服务是对全部计算基础设施的利用，包括处理CPU、内存、存储、网络和其它基本的计算资源，用户可以部署和运行任意软件，包括操做系统和应用程序。

 

 　　4.CAP定理：CAP 理论为：一个分布式系统最多只能同时知足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

• 一致性（Consistency）：一致性指 “all nodes see the same data at the same time”，即更新操做成功并返回客户端完成后，全部节点在同一时间的数据彻底一致。
• 可用性（Availability）：可用性指“Reads and writes always succeed”，即服务一直可用，并且是正常响应时间。
• 分区容错性（Partition tolerance）：分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然可以对外提供知足一致性和可用性的服务。