云原生内容分享(二)：云原生建设之微服务架构及应用上云策略

之乎者也·

已于 2024-02-02 23:30:48 修改

阅读量942

点赞数 17

分类专栏：云原生内容分享微服务架构与实践文章标签：云原生架构微服务

于 2024-01-25 00:09:59 首次发布

本文链接：https://blog.csdn.net/qq_45038038/article/details/135747369

版权

微服务架构与实践同时被 2 个专栏收录

50 篇文章 0 订阅

订阅专栏

云原生内容分享

38 篇文章 6 订阅

订阅专栏

随着容器技术和微服务等云原生基础技术的发展，应用的微服务化以及应用上云已经成为技术潮流。本文是对云原生提升培训的整理，主要介绍微服务的基本概念和架构、Service Mesh服务网格的基本概念，以及应用上云的评估策略等知识。

1、云原生应用实践

1.1 应用微服务化

1.1.1 微服务概念和核心思想

微服务概念最早在2014年由Martin Fowler和James Lewis共同提出，提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。微服务提倡服务依业务功能设计，以全自动的方式部署，并运行在独立部署的环境中。得益于Docker容器技术和Devops文化的兴起，微服务的思想和技术架构得到进一步的演化。

1）微服务特点

服务拆分粒度更细：服务模块和其它模块资源没有关系，就可以拆分为微服务。每个微服务都专注于一个特定的业务功能或业务逻辑
服务独立部署：每个微服务独立打包部署，互不影响。
服务独立维护：交由小团队来开发、测试和发布、运维，使得开发、测试和部署变得更加灵活和高效。
分布式：微服务是分布式系统的一部分，每个服务都可以独立地运行在不同的进程中，这提高了系统的可扩展性和容错性。
服务治理能力：统一的服务治理平台，对各个服务进行管理

2）微服务架构拆分

基于业务逻辑拆分：将系统中的业务模块按照职责划分为不同的微服务，每个单独的业务模块拆分为一个独立的服务。
基于可扩展性拆分：根据系统扩展性需求进行拆分。例如，将访问量较大、访问频率较高的业务独立拆分出来，以保证高性能业务需求和业务的独立性。
基于稳定性拆分：通过核心模块的划分或者主次链路的划分来进行微服务拆分。例如，分离出控制平面、数据平面和管理平面，这本质上也是通过核心模块划分来进行拆分的一种方式。
基于AKF扩展立方体拆分：这个立方体有三个轴线，每个轴线描述扩展性的一个维度：X轴代表无差别的克隆服务和数据，工作可以很均匀的分散在不同的服务实例上；Y轴关注应用中职责的划分，比如数据类型，交易执行类型的划分；Z轴关注服务和数据的优先级划分，如分地域划分。

3）微服务拆分前置条件

服务定义：服务之间调用通过接口描述来约定，约定内容包括接口名、接口参数以及接口返回值等；
服务发布和订阅：微服务架构通过注册中心进行服务配置和发现供调用者查阅
服务监控：全链路监控覆盖业务埋点、数据收集、数据处理和数据展示
服务治理：熔断或限流等方式减少服务之间的故障影响
故障定位：服务之间的依赖进行标记便于快速故障定位

1.1.2 微服务架构

微服务的提供者按照一定的格式描述服务，并向注册中心注册服务，声明提供哪些服务，完成服务发布。服务的消费者请求注册中心，查询所调用的服务地址，以约定的方式发起服务请求，获得请求的结果并解析。因此，微服务的架构包括以下：

服务描述：服务如何对外描述，包括：服务的名称、服务提供的信息、服务如何解析、服务返回的结果等。常用的服务描述方法包括：RESTful API、XML配置以及IDL文件。
注册中心：服务提供者将提供的服务及地址登记到注册中心。服务消费者从注册中心查询所需要调用的服务地址，发起请求。
服务框架：
- 服务通信协议：服务提供者和消费者之间通信的协议，比如四层TCP协议、七层的HTTP协议等
- 数据传输方式：服务提供者和消费者之间数据传输的方式，是同步还是异步、单连接还是多路复用方式
- 数据压缩格式：对数据进行压缩，减少网络传输的流量，比如JSON序列化、Java对象序列化以及Probuf序列化等
服务监控：对服务调用情况进行监控，包括指标收集、数据处理以及数据展示
服务追踪：记录服务调用的每一层链路，进行问题追踪和故障定位
服务治理：在故障场景下服务调用依旧正常可行，服务治理包括自动扩缩容、熔断、限流、隔离等方法

1.1.3 微服务架构最佳实践

围绕微服务架构，构建微服务基础架构平台，可以选择现成的开源项目如Spring Cloud，首先部署最基本的服务功能如服务发现、服务路由和服务容错，再到服务网关和API接口提升开发效率，最后是提升测试和运维效率。

自动化测试：包括单元测试、集成测试和系统间的接口测试、性能测试等
自动化部署：包括版本管理、资源管理、部署操作和回退操作等
配置中心：包括配置版本管理、增删改查管理、节点管理、配置同步、配置推送等
接口框架：轻量级的通信方式，一般采用HTTP/REST或RPC统一接口协议
API网关：外部系统访问的接口，包括接入鉴权、权限控制、传输加密、请求路由、流量控制等
服务发现：服务自动注册和发现，服务信息注册到服务注册表中
服务路由：从微服务节点中挑选出可用的节点发起请求，通常和服务发现一起实现
服务容错：熔断、限流和隔离等容错措施减少故障半径，避免故障扩散
服务监控：搜集系统信息并进行分析、告警、提前预警，做到及时发现
服务跟踪：监控服务运行的微观信息，服务之间的链路调用情况等
服务安全：保证业务和数据的安全性，监管和合规性要求

在微服务基础架构平台的基础知识，应用微服务化推荐步骤如下图所示：

1.2 Service Mesh服务网格

1.2.1 Service Mesh概述

随着微服务架构逐渐成为主流，开发者们开始将多个服务组合在一起来构建应用程序。微服务架构强调服务的独立性和自主性，使得服务间的通信变得复杂。Service Mesh在这种背景下应运而生，为服务间的通信提供了新的解决方案。Service Mesh定义如下：

A Service Mesh is a dedicated infrastructure layer for handling serviceto-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the Service Mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

Service Mesh是在基础架构层处理服务间的通讯，实现云原生复杂的服务拓扑情况下的可靠请求分发。在实现上是一组轻量化的网络代理，这些代理透明的部署在应用周边，无需应用感知。简单来说，Service Mesh相当于云原生时代的TCP/IP，解决应用程序网络通信、安全及可见性问题。Service Mesh在技术演进上目前经历了六个阶段：

第一阶段：控制逻辑和业务逻辑耦合
第二阶段：公共库将控制逻辑集中在一起作为单独部署工具包
第三阶段：通过代理包含相应的控制逻辑，实现和应用解耦
第四阶段：由Sidecar处理所有网络请求，转发给应用本身
第五阶段：服务网格模式，每个服务有一个Sidecar与之匹配
第六阶段：增加控制平面实现代理的访问控制和度量指标收集

在Service Mesh的产品实现上有Linkerd、Envoy、Istio、AWS APP Mesh等多种实现，其中Istio是现下最为流行的Service Mesh产品。

1.2.2 基于Istio的服务网格实现

Istio是功能强大的开源服务网格实现，具备流量控制、安全管控、可观测性以及策略等功能，同时支持多种不同的底层平台，如本地、虚拟机、云平台等部署环境。Istio的核心由控制平面和数据平面组成，其中Envoy是默认的数据平面代理。核心组件如图所示：

数据平面：使用Envoy，Sidecar代理，提供绝大部分流量控制功能
控制平面
- Pilot：将路由规则等配置信息转换为sidecar可以识别的信息，并下发给数据平面
- Citadel：专门负责安全的组件，内置身份认证管理功能，实现授权和认证工作
- Galley：将Pilot和底层平台解耦，负责配置的验证、提取和处理等

对K8s来说，Istio是以插件的形式对K8s的一种功能补齐，K8s本身只实现了运维部署、基本的服务发现功能，而Istio实现服务治理、熔断限流、动态路由和调用链跟踪等功能。

Gateway：集群的入口，外部流量通过这个网关来访问内部服务
VirtualService：制定路由规则，根据路由规则进行分发、重试和故障注入等
DestinationRule：提供服务的访问策略，如限流、负载均衡等
ServiceEntry：集群内服务请求外部服务的出口网关

2、应用上云实施路线

2.1 应用系统上云策略

前文介绍了应用微服务改造和服务网格基础架构的建设，那么哪些应用适合上云，应用上云的评估标准是怎样的，重要业务系统是否适合上云等。在实际评估过程中参考6R评估模型：

Retire（退役）：停用丢弃应用程序
Retain（保留）：保留应用程序在当前的IT环境
Rehost（重新托管）：少量修改应用配置后重新部署到新的云基础平台
Refactoring（重构）：对应用程序代码或配置根据新的基础设施服务平台提供的技术工具和标准进行应用重构并发布运行
Rebuild（重建）：丢弃现有的应用程序代码，并基于新的云平台构建云原生应用
Replace（替换）：丢弃现有的应用程序并采购同类型的商业SaaS应用

2.1.1 应用迁云6R评估流程

在应用迁云的6R评估过程中，基于应用技术组件和业务情况、应用架构和应用数据存储及专家建议等因素，进行评估决策，最后评估得到处置的结果为Retire、Retain、Rehost、Refactoring、Rebuild或Replace。

当然以上决策流程仅供参考，实际应用是否上云，其中的利弊还是需要经过反复论证的，否则纯粹为了追求技术架构的先进性，为了上云而上云，对后续生产运维架构的稳定性和业务的可用性都带来极大的挑战。

2.1.2 应用迁云资源需求

应用迁云的资源需求根据应用的架构高可用、数据增长趋势、服务的可用性以及扩展性等不同的需求特点进行评估，最终得到计算资源、存储资源、网络资源和运维需求等资源需求。

2.2 应用系统上云实施路线

应用系统实施上云主要分为4个流程：

迁移规范，包括迁移的标准和原则规范、评估和规划设计，以及实施要求等
迁移方法和工具，基于6R评估方法重点关注Rehost、Refactoring和Rebuild三种上云方式
职责和分工，迁云实施相关方包括信息部门、应用开发、云提供商以及迁移服务团队之间的工作范围和分工
迁移实施流程，按照业务调研->方案设计->迁移实施与验证三个阶段进行实施

3、总结

随着K8S等容器技术和微服务等云原生技术的发展，应用系统上云已成为一种技术潮流，但是不能盲目的追随。从Twitter（X）公司近一段时间应用下云的效果来看，整个开发和维护成本反而降低。应用上云固然可以带来资源性能上的可伸缩性，开发部署上的灵活性和便捷性，但相对应的单体应用的拆分带来服务组件之间的复杂性、云上基础设施环境和网络的架构复杂性，反而带来了应用架构上和稳定性上的不确定性以及运维成本的上升。从最近阿里云、滴滴等云上环境的可用性故障就可以看出，云基础环境的维护和高可用架构管理还有待验证，其中某一小基础组件的故障有可能导致的级联灾害、爆炸半径的不可控。所以当不能科学的评估是否上云，而是盲从技术偏好或其它因素主导，只能让运维人员负重前行，而重要业务系统是否应该上云，这里是要打上大大的问号的。