服务网格方案介绍
服务架构从单体发展到微服务,在云原生时代,微服务发展成服务网格。依托容器等技术,服务治理功能独立成基础设施层,与被治理的服务相互分离。
软件领域一直追求高可用、高性能、易扩展。在软件变得复杂之后,需要多人进行协作开发,服务的可用性、高性能和可扩展性受到越来越多的挑战。在一个庞大、复杂的单体服务下进行产品迭代,牵一发而动全身的窘境,简直是开发者的噩梦。为改变这种状况,很自然地会将单一庞大而复杂的服务做拆分,即进行服务化拆分。一个服务由多个微服务组成,微服务通过接口相互调用来提供完整的服务。软件架构大师马丁·福勒在2014年给出了微服务软件架构的综述性论文,译文见参考1。在微服务架构下,软件被拆分成有边界的、能独立开发和部署的、能相互通信的微服务。
服务拆分成微服务后,服务的边界明确了,功能和逻辑也清晰了,维护起来也更容易了。随着spring cloud全家桶的流行,微服务几乎成为软件开发的必选项。各种其他语言(golang,php等)也模仿了spring cloud提供了微服务框架。服务拆分成微服务后,带来显而易见的好处有以下部分。
- 服务之间边界清晰
- 每个服务更容易维护
- 服务独立部署
- 服务独立扩展
- 更好的隔离
- 多种技术栈容易共存
然而,软件领域经常提到“没有银弹”,微服务也不是银弹。细小的服务变多,会带来新的问题,诸如:
- 分布式架构让设计变得复杂
- 系统拆分成多个服务部署流程复杂
- 系统吞吐量变大但响应时间变长
- 排查问题复杂,涉及到多个不同服务
- 技术多元化、整体维护复杂度增加
针对这些问题,出现服务治理的概念。服务治理旨在提供对应的基础设施或机制,来解决众多微服务面临的一系列管理问题。微服务治理的框架或者套件一般提供以下的能力。
- 服务注册发现
- 服务链路追踪
- 服务弹性容错
- API网关
同样,服务拆分成更多的微服务之后,也需要一些自动化工具来提供研发效率,通常包括自动化测试和自动化部署。完全定制实现一套支持微服务的基础设施挑战比较大,尤其是需要支持多种开发语言时。在spring cloud及其模范者定义了微服务基础规范后,在云计算时代,伴随着容器技术的普及,云原生技术栈带了新的微服务治理方式。
提到服务网格,不得不提linkerd。目前流行的服务网格技术也是由linkerd提出的。在服务网格下,服务治理能力不是SDK形式提供给应用,而是单独提供一层基础服务设施层,为服务提供服务治理能力。参考2详细描述了微服务到服务网格的演变过程,如果对这个过程感兴趣,非常推荐阅读原文,本文直接简要描述这种模式下服务治理如何实现。
引用参考2中的示意图,如上图所示,服务网格提供一个sidecar(边车),该边车提供了服务发现、熔断、限流、负载均衡、超时重试、trace采集等等服务治理的能力。多个代理连接成一个网状结构,如下图所示。通过一个集中式的控制面板来控制各个