云原生时代如何更合理地落地微服务？（上）
极客时间编辑部
讲述：丁婵大小：7.21M时长：05:15
你好，欢迎收听极客视点。
微服务可以说是当前软件开发领域的技术热点，然而，随着云原生技术的推广，以及大量的微服务落地，反微服务的声音越发响亮。尤其是今年 Istio 1.5 版本发布，控制面由原先的多个微服务组件，合并成了一个单体应用，大大简化了架构与部署运维的复杂性，赢得了满堂喝彩。社区关于微服务模式质疑的声音此起彼伏。
架构没有好坏优劣之分，只有适合与不适合，但把微服务架构与单体架构进行比较，会发现微服务有以下优点：
微服务独立运行，通过进程的方式隔离，使故障范围得到有效控制、架构变得更可靠。
微服务架构由于故障得到有效隔离，整体可用性更高，有效降低了单点故障对整体的影响。
微服务的粒度更小，架构演进的影响面相应也更小，不需要大规模重构，只需调整个别微服务即可。
微服务架构可以实现以服务为粒度，通过接口共享重用，可重用性更高。
微服务架构可以根据服务对资源的要求以服务为粒度进行扩展，可扩展性更灵活。
服务拆分后，各个服务可以独立并行开发、测试、部署，交付效率大大提升，产品更新换代速度更快，用户体验更好。
虽然好处这么多，但在实际的落地中，要想享受微服务的福利，还需要具备一些先决条件。
1. 团队调整
需要重新组建团队，以服务为核心，按照业务领域划分全功能团队，改变原有的研发流程、决策机制。例如，倡导敏捷文化、快速迭代，做更多的自动化测试，加强 Code Review 等。
另外，微服务框架可以封装、抽象分布式场景下的一些常用能力，例如负载均衡、容错、远程通信等能力，可以让开发人员快速开发出高质量的服务。因此，在采用微服务之前，应该先进行微服务架构的选型、学习和试用，整个团队要对微服务相关的知识有一定的储备。
2. 基础设施建设
基础设施即代码，可以通过编程的方式管理虚机或容器，免去了手动配置、更新各个硬件的环节，这就使得基础设施极具弹性，能够快速、高效、准确地进行重复性操作。开发人员使用同一套代码或配置，就可以部署并管理成千上万台物理机。
另外，当服务数量增多、交付频繁的时候，故障次数可能会大幅度上升，因此需要构建全面地监控来发现故障并及时处理。当生产环境出现问题的时候，还需要将故障进行分级，评估影响面，然后分配给相应的负责人。
微服务架构的一个大优势就是快速交付，这不止体现在服务的粒度更小，还体现在整个流程更快速，因此需要打造基于自动化的工具链，以流水线交付的方式串联整个 DevOps 流程。这样小团队可以基于服务独立开发、测试、部署、运维。
这两点并不是采用微服务模式的充分必要条件，但如果能满足，微服务化的过程将事半功倍，后续维护和迭代也会顺风顺水，而不是叫苦连天。
另外，需要注意的是，微服务应该是随着业务的演进逐步拆分的。几乎所有成功的微服务架构都是从一个巨大的单体架构拆分出来的，几乎所有在一开始就构建微服务架构的案例，后续都遇到了巨大的困难。
面对一个新的业务和领域，我们很难在开始阶段就把业务梳理得很清晰，往往是经过一段时间、踩过一些坑后，业务内部的架构才能逐渐清晰起来。
并且，从一个已有的模块清晰的单体架构逐步划分服务，要比一开始就构建微服务简单的多。否则会有两个劣势，首先，第一版的交付时间会延后许多，因为有许多公共服务需要去构建；其次，服务很容易拆分得不合理，大大影响整个调用流程的性能，甚至可能需要花费很大的精力去处理分布式事务，最后不得不再将多个微服务整合成一个单体。
另外，只有当业务复杂度达到一定的程度后，微服务架构消耗的成本才会体现其优势。而微服务设计应该尊崇垂直划分优先原则，这样可以让团队自上而下地关注业务实现，端到端负责，避免跨服务多次调用引起的性能与沟通成本。
以上就是我们在落地微服务过程中需要注意的一些关键点，希望能为你提供一些参考。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论