微服务架构简介（5）— 到底要不要使用微服务

1.8 到底要不要使用微服务

微服务许诺过一些单体架构中难以实现的特性和功能，如可扩展性强、高可用、组件之间低耦合高内聚等。但是在落实微服务的时候不可避免地会遇到一些挑战。迁移成微服务的决定并不容易，需要思虑周全。而且这个概念还比较新，目前成熟的经验不多。随着越来越多拥趸的加入，我们希望在未来可以提炼出来一些成熟的模式。在一个组织准备转型成微服务架构时，需要考虑很多因素，如我们下面列出的这些。

1.8.1 组织认同度

确保所有即将参与到微服务转型中的人都接受过相应的培训。这个培训不只是纯技术技能，而是整个微服务的相关概念。大多数情况下，团队应该采用全栈开发的理念，也就是开发人员都需要知道一些DevOps知识。微服务架构中的开发人员对于其分管的微服务要有完全的支配权。让每一个开发人员意识到他们的职责不再按照前端开发、后端开发、运维等划分是很有必要的。团队要时刻准备好自己搞定所有的问题。如果有专门的DevOps人员当然好，但是每个团队还是要储备好DevOps相关能力做到自给自足。

1.8.2 体验 DevOps

确保组织中有一个成熟的运维团队和一天之内处理多个上线安排的流程。在单体架构向微服务架构转型的时候，每个服务需要单独进行监控，这对于基础设施和DevOps团队来说是一项额外的职责。如果想做到快速独立发布，就需要格外注意DevOps和监控系统，以确保上线无误或者出现问题之后能够及时回滚。

1.8.3 分析现有数据库模型

数据库的有效拆解是个大问题。某些时候现有的数据库设计得很难进行拆解，或者拆解时需要大幅调整一些数据库表结构的设计。你的组织中的数据库是什么情况呢？是否足够容易拆解成数个物理上和逻辑上有区别的小数据库呢？因为微服务中的数据是分散在多个不同的数据库中的，也就意味着数据库表之间没有任何的物理连接，这将导致大量代码的改动。

1.8.4 自动化和 CI/CD

微服务需要一些自动化测试工具和CI/CD工具如Jenkins和Team City等来支持频繁交付和上线。每一个服务应该有其自己单独的部署流水线和配置管理。这又会增加一些DevOps的开销。TDD（测试驱动开发）在这个方面非常重要。微服务需要单元测试和集成测试等自动化测试手段来保证持续交付。

1.8.5 集成

由于应用的不同部分运行在不同的地方（各个微服务中），因此需要做大量的集成工作来保证最终输出的正确性。在向微服务转型时，集成过程中的沟通和集成点的维护工作也是重要的开销来源。

1.8.6 安全

由于微服务中有大量的组件需要通过API或者消息队列相互通信，因此在通信过程中一定要考虑到安全性。基于凭证和基于令牌的微服务提供了很多解决安全问题的方案，但是对于开发和基础设施团队来说都会增加一些开销。任何一个准备转型为微服务架构的组织都需要综合考虑上述因素。成功的实施微服务可以给组织带来极大的可扩展性、高可用性，而且可以无宕机随时部署上线。

1.8.7 成功迁移的例子

Netflix公司在2009年成功完成了跨越性的由传统单体应用向微服务架构的转型。而且他们把自己在转型过程中得到的经验分享给了全世界。时至今日，Netflix有超过800个正在运行的微服务，每天会发生超过20亿个请求，这20亿个请求会在整个系统内部的微服务之间产生超过200亿个内部API的访问。

在Netflix开始从单体应用向微服务应用转型之时，微服务这词还没有出现。Netflix之前的单体应用非常庞大，他们最开始是从视频编码代码库迁移过去的，这是一个非面向客户的应用。在迁移成微服务架构的过程中，有一个最佳实践是：在单体架构向微服务迁移的时候，始终从非面向客户的组件开始。这些非面向客户的组件即使迁移失败了，也不会影响产品的主要业务流程。有了最开始的成功经验之后，他们才开始着手迁移那些关键的面向客户的组件。到2011年年底，他的产品已经整个迁移到了AW S上以众多微服务的方式运行。Netflix还开源了很多曾经帮助他们成功完成迁移的重要工具。

原文网址：https://www.epubit.com/book/detail/27566

内容来源：异步社区；版权属【人民邮电出版社 异步社区】所有，转载已获得授权；未经授权，不得以任何方式复制和传播本书内容，如需转载请联系异步社区。