service mesh框架对比-网易数帆

传统微服务架构与 Service MeshService Mesh框架对比：大多数企业的 Service Mesh 实践都不是从零开始，而是在原有微服务架构的基础上进行改造转型。那么，传统微服务架构在转型过程中会面临哪些问题？转型之后，企业内部不同角色的技术人员需要做出哪些改变？ 传统的微服务框架以 RPC 通信框架为基础，提供服务目录、注册发现、服务治理、流量管理、配置中心、全链路追踪等核心能力，并且向外延伸到安全审计、监控告警、统计分析、知识库等平台化能力。 以网易为例，他们的关注点在于如何在不中断业务的情况下，逐步将微服务架构支撑能力下沉到 Service Mesh 架构里。想要实现平滑过渡，除了需要在 Service Mesh 数据面和控制面组件中对服务注册发现、RPC 协议、配置下发进行扩展之外，还要对现有的上层研发工作台、运维效能平台等支撑平台进行兼容设计，避免支撑平台等基建重复建设。 在部署架构方面，Service Mesh 比传统微服务框架多了一层 Sidecar，且服务治理是基于流量的，因此会带来一系列的问题和挑战。 Sidecar 的运维复杂性问题，微服务架构支撑能力下沉后，也把复杂性下沉到了 Sidecar。Sidecar 面临着频繁更新的问题，但 Kubernetes 和 Istio 只解决了部分部署的问题，因此如何在不影响业务的情况下热更新 Sidecar 成为了新的挑战； 性能问题，某些对延时比较敏感的业务会对性能问题有较多顾虑，迫切需要对服务与 Sidecar、Sidecar 与 Sidecar 之间的链路进行性能优化； 整体架构的可观测性和排障效率问题，对业务方来说，服务注册发现、服务通信等原本客户端可见的过程现在都成了黑盒，在问题诊断和故障恢复方面需要更立体化的监控系统支撑。 Service Mesh 实践会如何影响企业内部员工的工作内容呢？ 传统模式下，开发和运维会有比较清晰的边界，开发人员负责服务运行稳定，运维人员负责服务运行的基础设施稳定。而进入到云原生时代，特别是容器化和 Service Mesh 落地之后，服务框架、服务治理、灰度发布等稳定性密切相关的能力都作为基础设施下沉了，开发和运维的边界开始变得模糊。所以，企业 IT 人员的职责也应该相应的进行重新划分。 架构师及基础架构团队，新的职责要求他们必须要非常理解业务，清楚地知道业务的服务依赖和服务治理规则，故障后能从业务视角进行排障和快速恢复。同时，他们还需要重新审视现有的技术架构和支撑平台建设，从业务视角出发进行设计，避免做出来的技术平台无法满足业务需求，或者不好用。 开发人员，原先开发人员要关注很多方面，例如服务框架、服务治理、环境一致性、遥测数据、客户端 SDK 版本升级等等，而现在，以上这些几乎统统不用关注，只需要专注于业务本身的逻辑开发； 运维人员，依托于 Service Mesh 打通的服务和基础设施边界，以及对服务的统一抽象，能够更好的从全局视角进行服务质量、依赖管理、容量规划、端到端监控等来保障产品稳定性。