采用微服务时必须解决的四个挑战

资讯频道 → 企业架构

2顶
0踩

2016-05-24 17:07 by 副主编 mengyidan1988 评论(0) 有9470人浏览

微服务架构

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

引用

原文：4 Challenges You Need to Address with Microservices Adoption
作者： Saba Anees，AppDynamics公司的内容运营专员
翻译：孙薇

在过去几周，我们介绍了微服务的概念，以及它在商业计划中的角色，还有企业迁移到微服务模型的方式——迁移到微服务的工作对企业提出了很大的挑战。在本周的文章中，我们将会对迁移到微服务时可能遇到的障碍，以及付出的努力最终所带来的好处进行深入探究。

微服务架构
微服务架构比原有系统要复杂得多，由于团队必须要管理与支持许多移动的部件，整体环境愈加复杂。其中一些必须要考虑的问题包括：

在添加更多的微服务时，必须确保这些微服务能够一起扩展。颗粒度更细致，代表着可移动的部件更多，从而导致系统更加复杂。
参与交互的服务越多，可能的故障点就越多。聪明的开发者总会未雨绸缪，为解决故障制定好计划。
将功能从单一整体化架构向微服务架构迁移时，会有很多持续通讯的小型组件产生，追踪单个业务事务在不同层面中的性能问题可能非常困难，因此，我们可以通过调用各种相关方法，包括自定义header、token或ID来解决。
由于微服务是无状态的、分布式的、独立的，因此传统的日志记录方式不再实用——就算想要简单地定位某个问题，都有可能制造出过多日志。微服务的日志必须能与跨平台的事件相关联。

其他要考虑的事情包括：

1.运营与基础架构：开发团队必须与运营团队更加紧密地合作，否则由于多个运营同时进行，情况会失去控制。

2.支持：对微服务安装提供支持和维护，比之前为单一整体式应用提供支持维护要困难得多。微服务的每个部件都可能涉及了多种框架及语言，在提供支持时，近乎无限的复杂度会影响相关人员添加服务的决策。如果某个团队成员希望创建一个使用深奥语言的新服务，很可能会影响到整个团队，因为大家必须确保这个新服务能够与现有的部分协作。

3.监控：在添加新服务时，维护与配置监控的能力也会是一个挑战，必须依赖自动化来确保监控跟得上服务规模的变化速度。

4.应用安全：架构中服务的发展为黑客、解密高手与犯罪分子制造了更多侵犯的目标。要跟踪各种运营系统、框架与语言会导致负责安全的团队将全部精力放在确保系统不易受到攻击方面上。

5.请求：在服务间发送数据的方式之一就是使用request header，它可以包含类似身份验证这样的细节，从而减少了所需的请求数量。但当这类数据发送大批量进行时，就会增加对各个团队合作的需求。

6.缓存：缓存有助于减少所需的请求数量，涉及多个服务的请求在缓存后会迅速变得复杂起来，需要不同服务及其开发团队进行沟通。

7.容错性：微服务的口号就是“互相依赖”。各项服务必须能经受得住直接的失败与无法解释的超时问题。故障可能会产生多米诺效应，通过某些服务产生级联效应，并可能会让某些服务失效。在这种环境下，容错也比在单一整体式系统中要复杂得多。

关注DevOps
在旧式开发环境中，IT部门中负责不同功能的部门合作很少，随着运营、开发与质量保证（QA）团队合作形式的发展，以及贯通整个软件开发流程的沟通加强，最终出现了DevOps。DevOps并不是由某个人或单个小组所担任的角色，它实际上是将有助于运营与开发密切合作的架构进行了概念抽象。在微服务架构中，开发者负责创建系统，以成功交付最终的产品。

随着大型及小型公司逐渐向微服务平台迁移，开发者也必须随之发展。由于部署微服务非常简单，开发者会逐渐参与到代码部署与产品监控的工作中。这种方式与传统案例产生了对比：在过去开发者负责编写代码，将其交付给另一支团队（DevOps）来执行部署与维护；而现在开发者与DevOps逐渐融合成更小的应用团队，主要负责三项工作：应用的构建、部署与监控。

微服务正在改变团队的组成方式，让公司得以围绕着特定的服务来创建团队，并赋予它们自治权以及一定范围内的责任。这种方式可以让公司根据瞬息万变的业务需求而快速作出调整，且不会影响到核心业务，同时也方便新人快速融入团队。

开发者可能要应对的其他挑战包括：