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

原文： 4 Challenges You Need to Address with Microservices Adoption
作者： Saba Anees，AppDynamics公司的内容运营专员
翻译： 孙薇
责编： 钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件[email protected]，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008申请入群，备注姓名+公司+职位。

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

微服务架构

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

• 在添加更多的微服务时，必须确保这些微服务能够一起扩展。颗粒度更细致，代表着可移动的部件更多，从而导致系统更加复杂。

• 参与交互的服务越多，可能的故障点就越多。聪明的开发者总会未雨绸缪，为解决故障制定好计划。

• 将功能从单一整体化架构向微服务架构迁移时，会有很多持续通讯的小型组件产生，追踪单个业务事务在不同层面中的性能问题可能非常困难，因此，我们可以通过调用各种相关方法，包括自定义header、token或ID来解决。

• 由于微服务是无状态的、分布式的、独立的，因此传统的日志记录方式不再实用——就算想要简单地定位某个问题，都有可能制造出过多日志。微服务的日志必须能与跨平台的事件相关联。

其他要考虑的事情包括：

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

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

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

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

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

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

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

关注DevOps

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

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

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

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

• 了解如何组合微服务架构的JavaScript开发者短缺；

• 理解及实现物联网服务；

• 协助公司将科技引入商业计划与策略上；

• 让业务经理了解：怎样应用开放API来加强现有产品线，并在市场上开拓新的机遇；

• 如何简化开发堆栈，选择正确的技术，并在供应商提供的中间件没有价值时提出拒绝；

• 从Netflix等行业领导者那里学习经验，并决定实现哪些微服务对公司最有好处；

• 了解这一点：很多供应商尚未建立起稳定的微服务平台；

• 同一时间内管理及运营的个体微服务或达数百，要能应对这种压力；

• 管理日益增长的复杂团队网——由尚未完全了解微服务方法的运营者、架构师、开发者、QA团队以及整合者所组成。

开始转变

一旦转变过程开启，你就会发现之前预想不到的新挑战出现，包括：

• 转移到微服务上的工作负载应该有多少？
• 是否该允许代码迁移到不同服务上？
• 在运营持续时，如何确定每个微服务的边界？
• 如何监控微服务的性能？

想要了解更多信息，请点击这里阅读英文电子书全文《如何使用微服务构建与拓展》。