微服务

概述

优势

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

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

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

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

缺点

微服务另外一个主要缺点是因为微服务是一个分布式系统，其使得 总体变得复杂。开发者须要选择和实现基于消息或者 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 等容器技术相结合。