微服务到云原生

微服务

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

架构演进

微服务架构区别于传统的单体软件架构，是一种为了适应当前互联网后台服务的「三高需求：高并发、高性能、高可用」而产生的的软件架构。

单体应用程序的优点

• 开发简单，功能都在单个程序内部，便于软件设计和开发规划。
• 容易部署，程序单一不存在分布式集群的复杂部署环境，降低了部署难度。
• 容易测试，没有各种复杂的服务调用关系，都是内部调用方便测试。
• 高效通信，程序间可直接调用，通信成本低。

单体应用程序的缺点

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断。
• 代码维护难：代码功能耦合在一起，依赖程度过高，新人不知道何从下手，牵一发而动全身。
• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长。
• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉。
• 扩展性不够：无法满足高并发情况下的业务需求。

微服务架构的优点

• 代码解耦易维护：每个服务独立开发，只专注做一件事，逻辑清晰，新人容易上手。独立应用更易优化，
• 多团队协作开发：每个服务都能够由专注于该服务的团队独立开发。开发人员可以自由选择任何有用的技术，只要该服务符合API要求。
• 独立按需扩展：每个服务都可以独立部署，独立调整资源。可以仅部署满足其容量和可用性限制的服务的实例数。此外，可以使用最符合服务资源要求的硬件。
• 独立运行稳定：每个服务独立运行，发生故障影响面可控，不会导致整个系统down掉。

微服务架构的缺点

• 应用间通过网络调用，通信成本高，通信效率降低。网络间调用容易出现问题，失败机率增大。应用规模变大后，服务治理难度增大。
• 系统整体架构及调用关系复杂，开发人员对整个系统了解会有局限。
• 应用间调用会产生分布式事务，业务实现难度更大，对开发人员要求更高。

微服务现状

为了解决上面微服务架构缺点「服务治理」就出现了。出现了众多的组件，如：服务注册、配置中心、服务监控、服务容错（降级、熔断、限流、超时、重试）等。幸好，有巨人的肩膀可以借给我们站上去，通过引入「微服务框架」来帮助我们完成服务治理。

Spring cloud Alibaba 体系

Spring Cloud 体系

下一代微服务的发展

在微服务体系中，架构团队一般会为应用封装各种服务治理能力的SDK，这种做法虽然保障了应用的正常运行。缺点同样明显，每次开发团队迭代升级新功能都需要各个部门参与升级才能使用。

尤其是 bugfix 版本，往往需要强推业务方升级，造成很大程度上的不方便。

随之而来的就是应用使用的 SDK 版本差别非常大，生产环境同时跑着各种版本的 SDK，这种现象又会让新功能的迭代必须考虑各种兼容，比如seata从jdk8升到jdk17一样，存在许多兼容性问题。

就好像带着枷锁前进一般，这样随着不断迭代，会让代码维护非常困难，有些祖传逻辑更是一不小心就会掉坑里。

同时这种 “重” SDK 的开发模式，导致异构语言的治理能力非常薄弱，如果想为各种编程语言都提供一个功能完整且能持续迭代的 SDK 其中的成本可想而知。

随之而来的解决方案：就是 Service Mesh（服务网格）

图为 边车设计模式

服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。

如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关心服务之间的那些原本通过服务框架实现的事情，比如 Spring Cloud、Netflix OSS 和其他中间件，现在只要交给 Service Mesh 就可以了。

Service Mesh 有如下几个特点：

• 应用程序间通信的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

目前几款流行的 Service Mesh 开源软件 Istio 、 Linkerd和MOSN都可以直接在kubernetes中集成，其中Linkerd已经成为云原生计算基金会 CNCF (Cloud Native Computing Foundation) 成员。

云原生

云原生是在云计算环境中构建、部署和管理现代应用程序的软件方法。现代企业希望构建高度可扩展、灵活且具有弹性的应用程序，可以快速更新以满足客户需求。为此，他们使用现代工具和技术，这些工具和技术本质上支持云基础设施上的应用程序开发。这些云原生技术支持快速、频繁地更改应用程序，而不会影响服务交付，从而为采用者提供了创新的竞争优势。

云原生应用程序服务架构

原生架构结合了开发团队用来构建和运行可扩展的云原生应用程序的软件组件。CNCF 将不可变基础设施、微服务、声明式 API、容器和服务网格列为云原生架构的技术块。

云原生架构总结为：微服务+容器化+DevOps+持续交付。CNCF，全称为Cloud Native Computing Foundation，中文译为“云原生计算基金会”。

不可变基础设施

不可变基础设施意味着用于托管云原生应用程序的服务器在部署后保持不变。如果应用程序需要更多计算资源，则会丢弃旧服务器，并将应用程序移至新的高性能服务器。通过避免手动升级，不可变基础设施使云原生部署成为一个可预测的过程。

微服务

微服务是小型的独立软件组件，它们作为完整的云原生软件共同运行。每个微服务都侧重于一个小而具体的问题。微服务是松散耦合的，这意味着它们是相互通信的独立软件组件。开发人员通过处理单个微服务来更改应用程序。这样，即使一个微服务出现故障，应用程序仍能继续运行。

API

应用程序编程接口（API）是两个或多个软件程序用来交换信息的方法。云原生系统使用 API 将松散耦合的微服务整合在一起。API 会告诉您微服务想要什么数据以及它能给您带来什么结果，而不是指定实现结果的步骤。

服务网格

服务网格是云基础设施中的一个软件层，用于管理多个微服务之间的通信。开发人员使用服务网格来引入其他功能，而无需在应用程序中编写新代码。

容器

容器是云原生应用程序中最小的计算单元。它们是将微服务代码和其他必需文件打包在云原生系统中的软件组件。通过容器化微服务，云原生应用程序独立于底层操作系统和硬件运行。这意味着软件开发人员可以在本地、云基础设施或混合云上部署云原生应用程序。 开发人员使用容器将微服务与其各自的依赖项（例如主应用程序运行所需的资源文件、库和脚本）打包。

容器的优势

容器的一些优势包括：

• 与传统的应用程序部署相比，您使用的计算资源更少
• 您几乎可以立即部署它们
• 您可以更高效地扩展应用程序所需的云计算资源

云原生应用程序开发？

云原生应用程序开发描述了开发人员如何以及在何处构建和部署云原生应用程序。文化转型对于云原生开发非常重要。开发人员采用特定的软件实践来缩短软件交付时间，并提供满足不断变化的用户期望的准确功能。我们在下面给出了一些常见的云原生开发实践。

持续集成

持续集成（CI）是一种软件实践，在这种实践中，开发人员可以频繁地将更改集成到共享代码库中，而不会出错。小而频繁的更改可以提高开发效率，因为您可以更快发现问题并对其进行问题排查。CI 工具会自动评估每次更改的代码质量，以便开发团队可以更有信心地添加新功能。

持续交付

持续交付（CD）是一种支持云原生开发的软件实践。借助 CD，开发团队可确保微服务随时准备部署到云中。他们使用软件自动化工具来降低进行更改时的风险，例如引入新功能和修复应用程序中的错误。CI 和 CD 协同工作，实现高效的软件交付。

开发运维

DevOps 是一种改善开发和运营团队协作的软件文化。这是一种与云原生模式保持一致的设计理念。DevOps 实践使组织能够加快软件开发生命周期。开发人员和运营工程师使用 DevOps 工具实现云原生开发的自动化。

无服务器

无服务器计算是一种云原生模式，云提供商完全管理底层服务器基础设施。开发人员之所以使用无服务器计算，是因为云基础设施会自动扩展和配置以满足应用程序要求。开发人员只需为应用程序使用的资源付费。当应用程序停止运行时，无服务器架构会自动移除计算资源。

Docker

Docker是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。当前应用的运行时也从物理机时代、虚拟机时代向容器化时代演进。

Docker 的理念为“Build, Ship and Run Any App, Anywhere”

容器化解决了软件开发过程中一个令人非常头疼的问题，用一段对话描述：

测试人员：你这个功能有问题。

开发人员：我本地是好的啊。

开发人员编写代码，在自己本地环境测试完成后，将代码部署到测试或生产环境中，经常会遇到各种各样的问题。明明本地完美运行的代码为什么部署后出现很多 bug，原因有很多：不同的操作系统、不同的依赖库等，总结一句话就是因为本地环境和远程环境不一致。

容器化技术正好解决了这一关键问题，它将软件程序和运行的基础环境分开。开发人员编码完成后将程序打包到一个容器镜像中，镜像中详细列出了所依赖的环境，在不同的容器中运行标准化的镜像，从根本上解决了环境不一致的问题。

Kubernetes

简介

k8s的出现是为了解决容器的编排问题：

随着Docker技术的兴起，业务规模逐渐扩大，容器越来越多，运维人员的工作越来越复杂，这个时候就需要编排系统解救运维同学。尽管Docker为容器化的应用程序提供了开放标准，但随着容器越来越多出现了一系列新问题：

• 如何管理、协调和调度这些容器？
• 如何在升级应用程序时不会中断服务？
• 如何监视应用程序的运行状况？
• 如何批量重新启动容器里的程序？

为了解决此问题，Kubernetes出现了

一个成熟的容器编排系统需要具备以下能力：

• 处理大量的容器
• 服务注册发现、负载均衡
• 鉴权和安全性
• 管理服务通信
• 多平台部署

理念：自动化的容器部署、扩展和管理

K8S（Kubernetes）是Google研发的容器协调器，已捐赠给CNCF，现已开源。脱胎于Google内部久负盛名的大规模集群管理系统Borg，是Google在容器化基础设施领域十余年实践经验的沉淀和升华。

采用了非常优雅的软件工程设计和开源开放的态度，使得用户可以根据自己的使用场景、通过灵活插拔的方式，采用自定义的网络、存储、调度、监控、日志等模块。

Kubernetes在容器编排领域已经成为无可争辩的事实标准

问题与挑战

• 随着业务的不断发展，微服务的数量越来越多，微服务间的通信网络也变得十分复杂，微服务间的通信拓扑构成了一个巨大复杂的网络，治理难度加大。
• 对于流量管控功能较弱，服务间访问的管理如服务的熔断、限流、动态路由、调用链追踪等都不在K8S的范围。
• 使用门槛高，由于框架组件多，对于业务开发人员，就需要掌握较多非业务的知识，增加了业务开发人员的挑战。
• 跨语言是微服务的优势之一，它可以让不同语言编写的服务通过暴露接口服务调用的方式开放能力。而使用类库的微服务，将被类库支持的语言限制。

Istio

随着分布式服务的部署——比如基于 Kubernetes 的系统——规模和复杂性的增长，它可能会变得更加难以理解和管理。需求可以包括发现、负载平衡、故障恢复、度量和监视。微服务体系结构通常还有更复杂的操作需求，比如 A/B 测试、canary 部署、速率限制、访问控制、加密和端到端身份验证。

服务到服务的通信使分布式应用成为可能。在应用程序集群内部和跨应用程序集群路由这种通信变得越来越复杂。 Istio 有助于减少这种复杂性，同时减轻开发团队的压力。

简介

Istio 是一个开源服务网格，它透明地分层到现有的分布式应用程序上。 Istio 强大的特性提供了一种统一和更有效的方式来保护、连接和监视服务。 Istio 是实现负载平衡、服务到服务身份验证和监视的路径——只需要很少或不需要更改服务代码。它强大的控制平面带来了重要的特点，包括：

• 使用 TLS 加密、强身份认证和授权的集群内服务到服务的安全通信
• 自动负载均衡的 HTTP, gRPC, WebSocket，和 TCP 流量
• 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制
• 一个可插入的策略层和配置 API，支持访问控制、速率限制和配额
• 对集群内的所有流量(包括集群入口和出口)进行自动度量、日志和跟踪

Istio为微服务应用提供了一个完整的解决方案，可以以统一的方式去检测和管理微服务。同时，它还提供了管理流量、实施访问策略、收集数据等功能，而所有这些功能都对业务代码透明，即不需要修改业务代码就能实现。

有了Istio，就几乎可以不需要其他的微服务框架，也不需要自己去实现服务治理等功能，只要把网络层委托给Istio，它就能帮助完成这一系列的功能。简单来说，Istio就是一个提供了服务治理能力的服务网格，是Kubernetes的好帮手。

Istio的多样化特性可以让你高效地运行分布式微服务架构，并提供一种统一的方式来保护、连接和监控微服务。

问题与挑战

• 底层技术门槛大大增加，需要有更专业的基础平台的开发和运维来维护该复杂的平台，对人员知识量及专业度要求极高。
• 平台层若出现问题，调查难度较大，一般业务开发对网络、存储、安全等方面知识薄弱，好在平台一般都会提供各种工具协助。
• 业务开发人员也需要了解容器化或服务网格相关原理，对人员技能要求较高。

下一代云原生？

WASM

WebAssembly 是一种新的编码方式，可以在现代的网络浏览器中运行 ，是一个可移植、体积小、加载快并且兼容 Web 的全新格式程序规范。WebAssembly 是由主流浏览器厂商组成的 W3C 社区团体 制定的一个新的规范。

**高效：**WebAssembly 有一套完整的语义，实际上 wasm 是体积小且加载快的二进制格式， 其目标就是充分发挥硬件能力以达到原生执行效率

**安全：**WebAssembly 运行在一个沙箱化的执行环境中，甚至可以在现有的 JavaScript 虚拟机中实现。在web环境中，WebAssembly将会严格遵守同源策略以及浏览器安全策略。

**开放：**WebAssembly 设计了一个非常规整的文本格式用来、调试、测试、实验、优化、学习、教学或者编写程序。可以以这种文本格式在web页面上查看wasm模块的源码。

**标准：**WebAssembly 在 web 中被设计成无版本、特性可测试、向后兼容的。WebAssembly 可以被 JavaScript 调用，进入 JavaScript 上下文，也可以像 Web API 一样调用浏览器的功能。当然，WebAssembly 不仅可以运行在浏览器上，也可以运行在非web环境下。

Serverless

2019 年，Serverless 被 Gartner 称为最有潜力的云计算技术发展方向，并被赋予是必然性的发展趋势。从行业趋势看，Serverless 是云计算必经的一场革命。

Serverless ，被称为无服务器，可以解读为一种软件系统架构方法，通常称为 Serverless 架构。代表的是无需理解、管理服务器，按需使用，按使用付费的产品。Serverless 产品中，其中可以包含存储、计算等多种类型的产品，而典型的计算产品，就是云函数这种形态。

• **免运维：**不需要管理服务器主机或者服务器进程。
• **弹性伸缩：**根据负载进行自动规模伸缩与自动配置。伸缩范围零到无穷大。
• **按需付费：**根据使用情况决定实际成本。
• **高可用：**具备隐含的高可用性。

分布式应用运行时（Dapr）

Dapr 是 Distributed Application Runtime （分布式应用运行时）的缩写。是一种可移植的，事件驱动的运行时，用于构建跨云和边缘的分布式应用。号称：“Any language, any framework, anywhere”