新兴技术的下一波浪潮正向我们涌来，人工智能、可穿戴设备、物联网及更多技术变得普及开来。许多组织现面临着管理这些整体式应用程序这个难题。当下，速度和灵活性必不可少。Netflix、Twitter、eBay和亚马逊等大型互联网公司采用的下一个架构创新是微服务。据互联网服务器供应商NGINX声称，68%的组织在使用或调查这种方法。
微服务架构正在IT行业备受追捧，因为它相比许多传统架构方法有诸多优势。比如在医疗保健领域，这种架构对新的解决方案来说大有希望，比如远程患者监控、使用物联网设备数据的预测建模、医疗工作流程自动化和面向精准医疗的生物信息学分析等。随着组织采用现代微服务架构，这六个因素可以帮助它们取得成功，同时补充现有的云和DevOps基础设施。
微服务架构如何补充云和DevOps?
微服务是一种软件开发和架构方法，它将应用程序构建为一组松散耦合、自治且可独立部署的服务。这些小型的业务驱动服务有明确定义的通信接口，这使得应用程序模块化、更易于构建和测试，并可以高效地独立部署。
微服务方法与云和DevOps相辅相成。多年来，云计算已趋于成熟，可以提供高效的基础设施解决方案，用于快速构建原型、支持庞大的数据处理和生产需求，并带来比内部IT部门更高的服务水平。与此同时，DevOps有助于更快地交付优质软件，同时弥补开发团队和运营团队之间的差距。
结合微服务架构与成熟的DevOps实践有助于分散的团队更快地创新、控制自己的技术堆栈和标准、管理性能指标、管理开发和发布周期，最终缩短产品上市时间。与此同时，微服务可以通过将整体式应用程序分解成微服务并部署到云平台上，从而便于逐步迁移到云。通过这种方法，团队更容易模拟生产工作负载，确保软件的可用性、可扩展性和质量，同时提高发布频次。
微服务架构设计方面的六个考量因素
下列六个考量因素有助于使组织确保成功，同时补充现有的云和DevOps基础设施：
- 服务发现：在复杂的分布式系统中，团队根据负载大小扩展服务实例，这意味着服务实例的数量及其位置可能动态变化。拥有适当的服务发现机制可确保客户可以基于服务注册中心与合适的服务进行通信。
- 服务间通信：在微服务架构中，服务以同步或异步方式进行通信以完成事务。服务间通信机制协调这种通信。如果设计不力，服务间的过多通信会导致“繁琐”的应用程序和糟糕的性能。想进行优化，请使用这些经过验证的设计模式：
▲Saga模式：由某个事件或消息触发的一连串事务。
▲api网关：借助API网关，通过单个API调用来抽象处理针对多个API的调用。
▲命令查询职责分离(CQRS)：使用物化视图将读写分开来，并通过订阅事件来更新视图。
▲事件溯源：存储事件而不是状态;通过重放事件来获得状态。
▲服务网格：将服务间的网络通信卸载到某个软件组件，以确保弹性和服务发现等。
- 数据完整性：由于每个微服务都有自己的数据库，因此确保数据在涉及多个服务的事务之间具有一致性可能是个挑战。上述模式(如事件溯源、CQRS和Saga)有助于实现数据一致性。
- 安全性：加密机制以及强大的身份验证和授权工具可以确保静态数据和传输中数据的安全性。一些组织采用身份即服务和授权即服务解决方案。此外需要在API网关后面保护API，确保未经授权的用户无法使用令牌获得访问权限。
- 监控和运行状况检查：随着微服务架构中服务数量越来越多，确定和排查问题变得具有挑战性。比如说，单单一个事务可能跨多个服务调用，因此很难确定性能瓶颈的确切原因。使用分布式事务跟踪和运行状况检查API监控系统可确保应用程序在高效运行。借助合适的监控和检测，团队可以为关键指标创建可视化元素，收集历史数据以了解性能趋势，并在问题出现时收到警报。
- 质量保证：微服务通过在服务之间传递消息来处理请求。随着服务数量增加，自动化测试对于确保所有交互和通信都经过全面测试非常重要，包括单元测试、集成测试、组件测试和合约测试。此外，每个级别的全面测试确认服务可以独立于其他服务运行或与其他服务一起运行，以支持分布式事务。最后，测试表明整体架构足够灵活，可根据需要支持另外的数据源、框架或库。
更快的创新是目标
微服务架构是当今一个重要的IT趋势，这有充分的理由。与传统的架构方法相比，它有许多优势，并且大有希望。虽然要克服诸多挑战，但如果企业组织拥有精心设计的方法、全面组织的分布式团队以及可靠的DevOps流程，可以借助现代微服务架构更快地进行创新，只需构建新产品，并更新改造现有应用程序。
原文标题：Six Considerations for Adopting a Microservices Architecture
作者：Vinil Menon和Khushboo Shah
地址：http://developer.51cto.com/art/201908/601287.htm，51CTO译稿
微服务化的不同阶段 Kubernetes 的不同玩法
作为容器集群管理技术竞争的大赢家，Kubernetes已经和微服务紧密联系，采用Kubernetes的企业往往都开始了微服务架构的探索。然而不同企业不同阶段的微服务实践面临的问题千差万别，注定要在技术路线上产生分叉
微服务架构下的监控需要注意哪些方面？
微服务本身并没有一个严格的定义，不过从很多人的反馈来看，大家都达成了这样一个共识：微服务是一种简单的应用，大概有10到100行代码。我知道使用代码行数来比较实现其实很不靠谱，因此你能理解这个意思就行，不必过分拘泥于细节
微服务架构之「 调用链监控 」
「 调用链监控 」是在微服务兴起后才有的一种新流行的监控模式。因为在我们传统单体应用的项目中，不存在服务链/调用链的概念，所以也就根本没有调用链监控的需求了
一个知名网站的微服务架构最佳实现
在Medium，我们的技术堆栈始于2012年的单体Node.js应用程序。我们已经构建了几个卫星服务，但我们还没有制定一个系统地采用微服务架构的策略。 随着系统变得越来越复杂并且团队不断发展
最终，我们放弃了微服务
微服务被认为是一种理想的架构模式，因此，Steven Lemon 所在公司的领导层决定从单体架构向微服务架构迁移，这让整个开发团队在随后的的日子里苦不堪言，七大现实问题摆在面前无法解决，微服务架构的好处也没有享受到
微服务架构如何影响软件开发文化？
微服务，并不仅仅是一种代码构造方式。微服务概念一出现就引发了热烈讨论，很多文章都喜欢将其与整体式架构比较，乃至来自大型企业的用例等。然而，在说起微服务时，开发人员关注的往往是这场革命的技术意义
为什么会产生微服务架构？
Web应用架构受系统用户量、开发人员组织方式影响严重。过去二十年互联网迅速发展，Web架构也从单体式演进出微服务，背后还有比如 Martin Fowler 提出的理论支撑。虽然每个人都听说过微服务，但是很多人并不太清楚为什么要这么做
PHP微服务集群搭建
近些年微服务架构大行其道，趁着最近有时间，来捣鼓捣鼓微服务是怎么一回事。微服务的概念由 Martin Fowler 于2014年3月提出：微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调
「微服务架构」基于Nginx的三种微服务参考架构
NGINX从一开始就参与了微服务运动。 NGINX的轻巧，高性能和灵活性非常适合微服务。NGINX Docker映像是Docker Hub上排名第一的应用程序映像，您今天在Web上找到的大多数微服务平台都包含一个演示
微服务开发的 10 个最佳实践
微服务架构是将软件系统分解成可独立部署的自治模块，这些模块通过轻量级的、语言无关的方式进行通信，共同实现业务目标。软件系统是复杂的。由于人脑只能处理一定程度内的复杂性
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!