微服务架构与云原生
目录
文章目录
微服务架构与云原生
从微服务架构的思想，咱们能够感觉到微服务架构、DevOps 和容器技术天然地走到了一块儿，构成了云原生应用架构的雏形。web
在云原生时代，微服务的特色：编程
- 平台化：利用云做为一个平台，为微服务架构进行更多的赋能。
- 标准化：咱们但愿微服务自己的部署、运维，微服务之间与其它服务之间的通信都能作到标准化，让服务与服务之间的互联互通变得更容易，服务可以跨到不一样的平台上，作到一次编写、一次定义、多处运行。
- 微服务轻量化：让研发人员关心核心业务代码、业务逻辑的研发，而不是复杂的微服务治理相关的逻辑研发。
- 微服务的产品化：但愿能构建微服务相关的产品，以产品化的方式支持你们使用微服务架构，让它变得更好用、更易用。
微服务架构首先要面对分布式架构的内生复杂性。微服务框架须要可以解决服务通讯和服务治理的复杂性，好比服务发现、熔断、限流、全链路追踪等挑战。安全
微服务框架，如 HSF/Dubbo 或 Spring Cloud 以代码库的方式来封装这些能力。这些代码库被构建在应用程序自己中，随着应用一块儿发布和维护。网络
服务通讯和治理本质是横向的系统级关注，是与业务逻辑正交的。但在微服务架构中，其实现方式和生命周期与业务逻辑耦合在一块儿的。架构
微服务框架的升级会致使整个服务应用的从新构建和部署。此外因为代码库一般与特定语言所绑定，难以支持企业应用的多语言（polyglot）实现。负载均衡
SOA 采用中心化的服务总线架构，解耦了业务逻辑和服务治理逻辑；微服务架构回归了去中心化的点对点调用方式，在提高敏捷性和可伸缩性的同时，也牺牲了业务逻辑和服务治理逻辑解耦所带来的灵活性。框架
为了解决上述挑战，社区提出了 Service Mesh（服务网格）架构。它从新将服务治理能力下沉到基础设施，在服务的消费者和提供者两侧以独立进程的方式部署。运维
这样既达到了去中心化的目的，保障了系统的可伸缩性；也实现了服务治理和业务逻辑的解耦，两者能够独立演进不相互干扰，提高了总体架构演进的灵活性。同时服务网格架构减小了对业务逻辑的侵入性，下降了多语言支持的复杂性。分布式
Google, IBM，Lyft 主导发起的 Istio 项目就是服务网格架构的一个典型的实现，也成为了新的现象级 “网红” 项目。ide
上图是 Istio 的架构，逻辑上分为数据平面和控制平面：
- 数据平面由一组以 sidecar 方式部署的智能代理组成，负责截获应用网络流量，收集遥测数据而且执行服务治理策略；
- 控制平面中，Galley 负责配置管理，Pilot 负责下发配置，Mixer 负责策略检查和遥测数据聚合，Citadel 负责通讯中安全证书管理。
Istio 提供了一系列高阶的服务治理能力，好比：服务发现和负载均衡，渐进式交付(灰度发布)，混沌注入与分析，全链路追踪，零信任网络安全等，能够供上层业务系统将其编排到本身的 IT 架构和发布系统之中。
可是 Service Mesh 不是银弹，其架构选择是经过增长部署复杂性（sidecar）和损失性能（增长两跳），来换取架构的灵活性和系统的可演化性。
为了解决部署复杂性的挑战，社区和云服务商都在共同进行努力：
- 一方面简化服务网格自动化运维水平（好比阿里云经过 operator 大大简化了 Istio的升级运维和跨 K8s 集群部署的复杂度）；
- 另外一方面提供托管的服务网格服务，帮助用户关注在业务层面的服务治理而非基础架构实现。
关于性能问题：
- 一方面 Service Mesh 须要下降自身控制平面和服务平面的性能开销，好比尽量 offload mixer 负载，将治理策略执行下沉到数据平面完成；
- 另外一方面还须要从新思考整个通讯栈中应用与网络基础设施的边界。
为了实现容器应用之间的互联互通，Kubernetes 社区提出 CNI 网络模型，将容器网络连通性与底层网络实现的进行解耦，同时 K8s 提供了 Service, Ingress, Network policy 等基本元语来支持应用层的服务通讯和访问控制。可是这些能力远不能知足应用对服务治理的需求。
服务网格在 L4/L7 增长了流量管理、全链路可观测性、安全互联等新功能，这些是经过引入运行在用户空间的 Envoy 代理实现的，在提高灵活性的同时也不可避免地增长了性能开销。
为了系统化解决这个问题，社区在进行有趣的探索。好比在 Cillium 容器网络中，能够利用 eBPF/XDP 等操做系统和底层网络能力，将应用层的服务控制能力（如 Kube-Proxy 提供的 service, network policy）下沉到操做系统内核和网络层解决，并优化了 Service Mesh 数据链路，减小上下文切换和数据拷贝，有效地减小了性能开销。
目前 Service Mesh 技术还处在技术成熟度曲线的初期，除了在 L4/L7 层提供灵活的服务通讯功能，社区也在探索经过网络 Service Mesh[6] 实现灵活的 L2/L3 组网能力。咱们相信其会成为将来企业分布式应用通讯基础设施。
在这个过程当中会有一些新的理念和项目被持续创造出来，咱们须要可以理性地分析其业务价值和技术局限性。咱们要避免将 Service Mesh 做为万灵药，不要将应用集成、应用侧安全等业务逻辑下沉到服务网格中，避免咱们重蹈复杂性覆辙。
Service Mesh
另外一种抽象公共代码的方法是直接将这些代码抽象到一个反向代理组件。每一个服务都额外部署这个代理组件，全部出站入站的流量都经过该组件进行处理和转发。这个组件被称为Sidecar。
Sidecar不会产生额外网络成本。Sidecar会和微服务节点部署在同一台主机上而且共用相同的虚拟网卡。因此Sidecar和微服务节点的通讯实际上都只是经过内存拷贝实现的。
Sidecar只负责网络通讯。还须要有个组件来统一管理全部sidecar的配置。在Service Mesh中，负责网络通讯的部分叫数据平面（data plane），负责配置管理的部分叫控制平面（control plane）。数据平面和控制平面构成了Service Mesh的基本架构。
Sevice Mesh相比于微服务框架的优势在于它不侵入代码，升级和维护更方便。它常常被诟病的则是性能问题。即便回环网络不会产生实际的网络请求，但仍然有内存拷贝的额外成本。另外有一些集中式的流量处理也会影响性能。
流量治理
微服务一方面是把原来在静态编译时产生的能力与能力之间的关联关系，经过架构拆分推演到动态的运行时。所以在运行时，服务与服务之间是须要进行通信、协同，才能完成某一项具体的业务功能。当你们进行通信、协同时，就必定要对其通信过程进行管理，或者说要进行流量管理。例如，咱们要知道怎样从一个微服务找到另外一个微服务，以及怎样能保证一个微服务找到最佳的微服务实例跟它进行通信，这是一个比较复杂的过程，其中包括 RPC 能力、服务注册发现能力、动态配置管理能力以及服务降级能力等等。
为了减轻业务开发同窗的负担，不用重复的在每个微服务中写一遍微服务的流量管理的通用能力，所以你们开发了不少框架，好比在 Java 体系中，著名的 Spring Cloud 提供了一个分布式微服务管理框架；在 Go 语言的开源生态中也有像 Go Mirco 这样的体系；在阿里巴巴内部咱们也有像 HSF 这样的体系发展起来的微服务治理框架。
所以，从抽象层面能够看到一个服务包含了两个层面：
一个层面是自己的业务逻辑，也就是由微服务业务开发人员去编写的，功能实现与业务实现相关的代码。
另外一个层面是为了实现微服务与微服务之间通信、流量、服务治理的代码，咱们会将其抽象成一个框架，以下图中标出的 Spring Cloud。这样的抽象带来了一个问题，就是全部的通用能力都依赖于这个具体的框架。
假设在公司之中，除了 Spring Cloud 以外，咱们去引入另一些服务框架，如阿里巴巴 HSF 若是但愿和 Spring Cloud 框架上面编写的微服务进行通信的话应该如何去操做？这就要求 HSF 与 Spring Cloud 之间互联互通以及协议之间的互相理解。但其实这些框架之间每每并不具有这个能力。更大的一个问题可能在于，云原生时代咱们容许这些微服务的研发能用不一样开发语言及模型来进行编程。所以，框架之间的系统并非不是一对二的关系，也不是 仅仅是 Spring Cloud 与 HSF 的关系，多是 Java 体系与 JavaScript、Python、Go 体系这些微服务框架都须要打通的问题，它变成了一个 N to M 的 problem，来解决多语言、复杂环境中微服务的治理与管理问题。
这时，当咱们有了容器、容器平台、Pod 这些抽象，可以提供一个平台，而不是必需要彻底依赖于业务中的代码或 框架时，有没有更好的办法来解决刚才提到的问题？
如今有一个比较流行的概念叫 Service Mesh——服务网格。它的本质就是为了更好地解决流量治理在多语言、多环境场景下的问题，它的主要思想以下：
- 第一就是但愿把流量管理的这些框架能力从耦合在业务的二进制中抽象、剥离出来，造成一个流量管理的单独进程，并以 Sidecar 的模式部署在 Pod 中。经过操做系统级别的透明流量劫持工做，把全部的微服务之间的流量劫持到 Sidecar 中，而后经过 Sidecar 与 Sidecar 之间通信进行流量的转发与管理。这样问题就简单多了，咱们只须要让流量管理的 Sidecar 之间互相通信、可以进行互联互通。目前比较知名、流行的开源流量劫持和管理 Sidecar 实现叫作 Envoy。
固然，单单有了这层流量劫持与管理仍是不够的，还须要管控平面的支持。好比原来微服务体系作的服务注册、服务发现以及流量观测仍是须要的，这些策略和规则须要下发给流量管理的 Sidecar 代理。所以，咱们还须要构建一个管控平面来管理在 Pod 中部署的流量管理的数据平面的单点，让它们造成一个网状，造成一个集群。因此咱们须要有一些管控平面的能力，在开源中比较流行的一个管控平面实现叫 Istio。主要实现了三个能力：流量的配置、流量的安全、流量的观测。
咱们认为在云原生这个逐渐平台化的时代，大部分新的应用及场景都会尝试选用基于 Service Mesh 的技术进行微服务的流量治理。