实施微服务架构：用于构建下一代云应用程序

　　作者：Chandani Patel，Nupur Patel

　　“微服务”是软件架构领域最流行的流行语之一。虽然我们的第一篇文章讨论了微服务的基本原理和优势，但在本文中，我们将解释企业如何利用关键架构原则在实际用例中实现微服务。

　　如何从设计基于微服务的解决方案体系结构开始

　　基于微服务的解决方案架构并不总是最适合所有用例，使用一刀切的方法有几个缺点。在设计基于微服务的解决方案体系结构之前，企业解决方案架构师必须解决以下问题。

　　微服务架构是否适合该解决方案？

　　应该如何定义微服务架构？

　　在为应用程序的第一个版本构建微服务架构时，我们建议采用“整体式”方法。这意味着您以简单的方式构建应用程序，以首先验证您的想法。然后，应用此博客中包含的原则，将初始整体式架构扩展并演变为基于微服务的解决方案体系结构。创建架构纯微服务，不能为业务提供价值，这是没有价值的。整体架构模式将帮助您了解有关大型复杂系统的几个问题和限制（微服务架构可能会发生这种情况）。

　　1. 将应用程序分解为服务

　　微服务架构是一组松散耦合的服务，将应用程序分解为服务在微服务架构实现、部署和 CI/CD 中起着关键作用。

　　解决方案架构师可以根据需求和解决方案定义分解方法，没有“最佳”分解方法，但有常见的方法，可以帮助您在下面提到的几种服务中分解解决方案。要应用分解，您需要了解每个组件的需求和角色、多个组件之间的权重/链接以及整个解决方案的每个组件的更多因素。

　　分解策略：

　　按模块/业务能力分解：此方法建议为每个模块或功能定义每个组件，即消息传递，日志记录，设备通信，用户管理。这有助于您将整个功能/模块分配给单独的团队，其中各个团队将负责模块/功能

　　按域分解： 此方法建议定义要部署解决方案的区域，并进一步定义该区域的服务。定义与域驱动设计 （DDD） 子域对应的服务。DDD 将应用程序的问题空间（业务）称为域。一个域由多个子域组成。每个子域对应于业务的不同部分。例如用户管理、设备管理、设备通信

　　分解时要考虑的事项：

　　查找每项服务的边界，并使其与业务功能保持一致

　　专注于定义微服务的范围，而不仅仅是缩小服务。服务的（正确）大小应该是促进给定业务能力所需的大小

　　该服务应该具有很少的操作/功能和简单的消息格式

　　确保微服务设计确保服务的敏捷/独立开发和部署

　　每个服务都必须可单独测试和部署

　　服务必须具有凝聚力。服务应实现一小组强相关的函数

　　每个服务都应该足够小，以便可以由 6 名成员组成的小团队开发

　　应用程序必须易于理解和修改

　　该服务必须在负载均衡器基础结构（如 ELB）中可缩放

　　2. 微服务发现和注册

　　微服务架构使用服务注册中心来维护发送请求的服务位置，该注册表可以在服务端或客户端进行管理。服务可以自行注册，也可以通过第三方（部署脚本）注册服务。每个服务都应在服务启动时使用运行状况检查接口在注册表上注册自身。运行状况检查接口可帮助注册表检查服务可用性。定义服务注册表时，必须实现一种机制，使服务的客户端能够向一组动态更改的临时服务实例发出请求。

　　3. 微服务通信

　　为此，体系结构必须允许每个服务相互通信。以下是定义服务间通信的多种方法：

　　远程进程调用：远程过程调用将封装原则应用于集成服务。如果应用程序需要修改另一个应用程序的数据，则它通过调用另一个应用程序来实现 每个服务都可以维护其拥有的数据的完整性。此外，每个服务都可以更改其内部数据，而不会使其他每个应用程序受到影响。您可以使用grpc，Apache Thrift和REST进行此类通信。

　　消息：使用 Kafka、RabbitMq 等工具在服务间通信中使用异步消息传递。当每个请求都是独立的并且不需要任何回调时，这将起作用

　　域特定调用：使用域特定协议进行服务间调用，例如SMTP或IMAP用于电子邮件，RTSP，RTMP，HLS或HTTP用于媒体流

　　4. 微服务观察

　　观察是微服务框架的另一个关键点。这允许您调试和监视每个服务。在设计微服务时，有几个方面需要解决。

　　日志聚合：使用来自每个服务实例的集中日志。用户/审阅者可以搜索和分析日志。他们可以配置多个严重错误的警报，并按类别检查错误数。这可以通过将logstash集成为中央日志服务器来实现

　　运行状况检查：运行状况检查界面可帮助用户/审阅者检查服务是否可用。这可以通过创建具有静态响应的 REST 接口并集成负载均衡器来实现，该负载均衡器会定期检查 API 的运行状况并更新服务状态。

　　应用程序指标：它提供服务状态指标，包括信息，例如 – 每个 API 调用多少次？来自的最大请求数来自何处？此服务在后台运行，并与服务器的每个操作交互，因此您选择的服务应占用最小的运行时开销。例如，节点的Appmetrics，JAVA的Coda Hale

　　日志部署和更改：查看部署和其他更改何时发生非常有用，因为问题通常在更改后立即发生。例如，启用部署状态通知，启用应用程序崩溃通知

　　5. 微服务数据库管理

　　大多数服务需要在数据库中具有持久性数据。例如，设备服务存储有关设备的信息，用户服务存储有关用户的信息。

　　数据库管理策略：

　　在微服务框架中管理数据库有多种方法。

　　每个服务的数据库：将每个微服务的持久数据保密为该服务，并且只能通过其 API 访问

　　解决方案的共享数据库：使用由多个服务共享的（单个）数据库。每个服务使用本地 ACID 事务自由访问其他服务拥有的数据

　　混合数据库：分别创建一个通用的共享数据库和特定于服务的数据库，例如，在典型的物联网云平台即服务中，架构师可以选择将请求超时存储在特定数据库中，该数据库只能通过该模块公开的特定服务进行访问

　　管理数据库时要考虑的事项：

　　某些业务事务必须强制实施跨多个服务的不变量

　　某些业务事务需要查询由多个服务拥有的数据。例如，要检索用户设备，它将从用户服务和设备服务请求详细信息

　　某些查询必须联接由多个服务拥有的数据

　　有时必须复制和共享数据库才能扩展

　　不同的服务有不同的数据存储要求。例如，日志服务将使用LogStash，用户服务和设备管理将使用MongoDB

　　6. 微服务外部接口（API 网关）

　　外部接口是用户/应用程序与微服务交互的入口。实现 API 网关，为来自客户端的所有服务请求启用单个入口点。API 网关将对请求进行身份验证，并将代理/路由到实际服务。API 网关为受保护的端点实现安全性（在标头或查询参数中包含访问令牌）。企业架构师应设计 API 网关来负责安全性、应用程序数据保护和请求限制数量（每个用户、每个 IP 或每个应用程序），以防止 DDoS 攻击。

　　7. 微服务测试

　　尝试测试与其他服务通信的应用程序时，可以执行以下两项操作之一：

　　部署所有微服务并执行端到端测试：在测试环境中模拟生产，并在部署之前运行端到端测试。此方法将测试实际用例并确保服务质量。这种测试的缺点是它们非常耗时且调试非常困难

　　在单元/集成测试中模拟其他微服务：模拟外部服务并运行单元测试和集成测试。这种方法非常快，但不能保证生产安全

　　测试微服务的常见建议是使用组合集成测试和单元测试。将一些测试作为单元测试运行，其中一些作为集成测试运行，以确保解决方案中所需的质量。

　　在计划测试时，您必须将服务组件测试和服务集成合同测试作为测试过程的一部分。您可以在开发中使用多个测试工具/框架，例如Junit，Java和Mocha的Spring Cloud Contract，Chai，Sinon，Proxyquire等，用于Nodejs。您可以通过checkstyle生成HTML报告，以验证测试报告和代码覆盖率。

　　理想情况下，建议对任何源代码使用 80% 的代码覆盖率。

　　8. 微服务;持续集成和部署

　　每个服务都部署为一组服务实例，以实现吞吐量和可用性。

　　CICD战略：

　　每个实例多个服务： 在同一主机（物理或虚拟）上运行多个服务。例如，将所有 NodeJS 服务部署在 EC2 实例上作为单独的服务。当您处于开发阶段或有少量用户访问您的应用程序时，这将起作用。随着用户的增长，此方法会导致资源冲突、内存和 CPU 利用率问题以及对服务行为的监控不足等问题。

　　每个主机的服务实例： 在每个主机上部署一个服务。这通过一种有效的方法来平衡负载，例如当特定服务的负载很高时，这克服了每个实例多个服务的问题。在这种情况下，您可以将部署扩展到单个服务的多个实例。这种模式也有一个缺点;假设您有一个不经常使用的服务，即订单争议，但这将部署在一个实例上，您不能将这里的 CPU 和内存资源用于另一个服务

　　无服务器部署： 使用可删除服务器和基础结构管理的部署服务。它允许您压缩包，将其部署到应用程序服务上，并根据请求向您收费。在此方法中，您无需担心资源管理和负载管理。将服务设计为在没有服务器的情况下运行，使用公共资源（如用于文件存储的 S3 或 Azure 存储）、将 Dynamodb 或 Azure 数据库作为数据库、SNS 或事件网格用于在两个服务之间进行通信，SES 作为电子邮件服务。流行的框架组件包括AWS lambda，Google Cloud function，Azure函数

　　CICD期间要考虑的事项：

　　在定义部署微服务体系结构时，最好检查以下事项。

　　开发中使用的语言、框架和框架版本

　　每个服务都在工作，并且可以单独部署和扩展（例如，部署4个服务进行设备管理）

　　每个服务都与另一个服务隔离

　　为每个服务添加 CPU 和内存约束

　　监视每个服务

　　检查部署成本

　　9. 微服务部署平台

　　您还可以使用部署平台为无服务器和基于服务器的模型自动部署微服务。

　　如果你有一个庞大的系统，有多个集成服务，可以自我管理服务器实例和服务，这通常是一个经济高效的解决方案。您可以将 AWS 云形成和任务定义与 Docker swarm 模式和 Kubernetes 结合使用，以集中部署、扩展和管理所有应用程序。AWS 云形成允许您使用单个文件对基础设施进行建模和预置，任务定义允许您为您的环境定义多个 Docker 映像。一旦环境启动，任务定义将负责所有服务，即如果您的服务崩溃，它将自动启动新的 Docker 实例。

　　如果您的解决方案很小，但需要服务，那么您可以将服务部署到 AWS Elastic Beanstalk 等 PaaS 平台，它允许您在熟悉的服务器（如 Apache、Nginx、Passenger 和 IIS）上部署和扩展使用 Java、.NET、PHP、Node.js、Python、Ruby、Go 和 Docker 开发的 Web 应用程序和服务。它根据您使用的资源收费。

　　要部署无服务器代码，您可以使用多种工具，如 claudia.js它允许您自动执行 AWS lambda 和 API 网关部署。

　　实现示例：

　　假设我们正在使用微服务架构构建物联网解决方案，该架构包括设备连接、用户管理、警报和规则引擎。除此之外，该解决方案还必须向第三方应用程序（如 Android 和 iOS）公开 REST API 详细信息。

　　由于我们的解决方案使用微服务架构，因此它将解决方案划分为多个服务，例如：

　　API 网关（例如，提供安全网关（使用 API 密钥）的快速网关，包括速率限制等多项功能，将请求路由到微服务）

　　面向 API 微服务的快速服务

　　用于服务间通信的塞内卡微服务工具

　　MongoDB集群作为数据库。

　　Redis for Service Registry & Event Store

　　Docker、Jenkins 和 Cloud formation 用于部署

　　审核编辑：郭婷