转载

采用微服务架构的六个考量因素

【51CTO.com快译】新兴技术的下一波浪潮正向我们涌来，人工智能、可穿戴设备、物联网及更多技术变得普及开来。许多组织现面临着管理这些整体式应用程序这个难题。当下，速度和灵活性必不可少。Netflix、Twitter、eBay和亚马逊等大型互联网公司采用的下一个架构创新是微服务。据互联网服务器供应商NGINX声称，68%的组织在使用或调查这种方法。

微服务架构正在IT行业备受追捧，因为它相比许多传统架构方法有诸多优势。比如在医疗保健领域，这种架构对新的解决方案来说大有希望，比如远程患者监控、使用物联网设备数据的预测建模、医疗工作流程自动化和面向精准医疗的生物信息学分析等。随着组织采用现代微服务架构，这六个因素可以帮助它们取得成功，同时补充现有的云和DevOps基础设施。

微服务架构如何补充云和DevOps?

微服务是一种软件开发和架构方法，它将应用程序构建为一组松散耦合、自治且可独立部署的服务。这些小型的业务驱动服务有明确定义的通信接口，这使得应用程序模块化、更易于构建和测试，并可以高效地独立部署。

微服务方法与云和DevOps相辅相成。多年来，云计算已趋于成熟，可以提供高效的基础设施解决方案，用于快速构建原型、支持庞大的数据处理和生产需求，并带来比内部IT部门更高的服务水平。与此同时，DevOps有助于更快地交付优质软件，同时弥补开发团队和运营团队之间的差距。

结合微服务架构与成熟的DevOps实践有助于分散的团队更快地创新、控制自己的技术堆栈和标准、管理性能指标、管理开发和发布周期，最终缩短产品上市时间。与此同时，微服务可以通过将整体式应用程序分解成微服务并部署到云平台上，从而便于逐步迁移到云。通过这种方法，团队更容易模拟生产工作负载，确保软件的可用性、可扩展性和质量，同时提高发布频次。

微服务架构设计方面的六个考量因素

下列六个考量因素有助于使组织确保成功，同时补充现有的云和DevOps基础设施：

服务发现：在复杂的分布式系统中，团队根据负载大小扩展服务实例，这意味着服务实例的数量及其位置可能动态变化。拥有适当的服务发现机制可确保客户可以基于服务注册中心与合适的服务进行通信。
服务间通信：在微服务架构中，服务以同步或异步方式进行通信以完成事务。服务间通信机制协调这种通信。如果设计不力，服务间的过多通信会导致“繁琐”的应用程序和糟糕的性能。想进行优化，请使用这些经过验证的设计模式：

▲Saga模式：由某个事件或消息触发的一连串事务。

▲API网关：借助API网关，通过单个API调用来抽象处理针对多个API的调用。

▲命令查询职责分离(CQRS)：使用物化视图将读写分开来，并通过订阅事件来更新视图。

▲事件溯源：存储事件而不是状态;通过重放事件来获得状态。

▲服务网格：将服务间的网络通信卸载到某个软件组件，以确保弹性和服务发现等。

数据完整性：由于每个微服务都有自己的数据库，因此确保数据在涉及多个服务的事务之间具有一致性可能是个挑战。上述模式(如事件溯源、CQRS和Saga)有助于实现数据一致性。
安全性：加密机制以及强大的身份验证和授权工具可以确保静态数据和传输中数据的安全性。一些组织采用身份即服务和授权即服务解决方案。此外需要在API网关后面保护API，确保未经授权的用户无法使用令牌获得访问权限。
监控和运行状况检查：随着微服务架构中服务数量越来越多，确定和排查问题变得具有挑战性。比如说，单单一个事务可能跨多个服务调用，因此很难确定性能瓶颈的确切原因。使用分布式事务跟踪和运行状况检查API监控系统可确保应用程序在高效运行。借助合适的监控和检测，团队可以为关键指标创建可视化元素，收集历史数据以了解性能趋势，并在问题出现时收到警报。
质量保证：微服务通过在服务之间传递消息来处理请求。随着服务数量增加，自动化测试对于确保所有交互和通信都经过全面测试非常重要，包括单元测试、集成测试、组件测试和合约测试。此外，每个级别的全面测试确认服务可以独立于其他服务运行或与其他服务一起运行，以支持分布式事务。最后，测试表明整体架构足够灵活，可根据需要支持另外的数据源、框架或库。