企业云原生之微服务全面解析.pdfVIP

企业云原生之微服务全面解析

承A【导读】微服务是企业应用及数据变革升级的利器，是数字化转型及

运营不可或缺的助产工具，企业云原生更离不开微服务，同时云原生的既要最

大化发挥微服务的价值，要最大化弥补微服务的缺陷。本文梳理了微服务基

础设施组件、服务网格、微服务技术框架知识，并提出了框架选择建议以及微

服务的缺点及难题。

1、单体应用

传统应用系统多为单体应用、经典三层架构部署：“应用-数据库-中间

件”，关于该业务领域的功能实现全部在一个软件工程中进行开发，集成发布

打成一个程序包更新，其主要优点为：

（1）系统整体架构笥洁清晰，测试、部署及运维比较简便，中小型项目开发

快捷；

（2）资源占用较低，不需要分布式开销；

单体由于将所有功能模块耦合在一起，导致其存在如下缺点:

（1）系统耦合度高，容错能力低，小的问题可能导致整体的不可用;

（2）开发周期长、程序代码冗肿，调试复杂、启动时间慢；

（3）Bug修复成本高，每一次线上Bug修复需要全局替换、发布；

（4）扩展性差，应对高并发、高吞吐能力差；

（5）交付周期长，所有功能一起构建、一起部署、一起发布，代码集成复

杂，出错率高；

（6）对于大型项目以及需求变化频次高的系统，重构是必然。

综合单体应用的优缺点，其比较适合变化频次较低的中小型系统，具体表现为

用户量稳定、需求变化不大以及整体开发工程量微小的项目，比较经典的系统

有：资产管理系统、资质管理系统、财务系统、人事系统等。

2、微服务

2.1微服务基础设施组件

微服务是云原生的主要技术内容之一，是云上应用的主流架构，同时是应用

系统及数据适应云平台的最佳选择。移动互联时代，用户体量及访问量几何式

倍增，同时用户需求和行业环境等皆处于快速化的状态，传统的单体应生受

限于其耦合度高、扩展性差、迭代缓慢等缺点已基本不适用与主流应用系统,

微服务应运而生。微服务本质上是对传统的单体应用根据业务领域和模块进行

划分、解耦，拆分成一个一个单独部署、运行的微小应用。

例：单体销售系统重构微服务商城系统

通过拆分单体应用为微服务，实现对业务系统的充分解耦，可以收获以下优

势:

(1)系统松耦合、服务高内聚，代码聚焦指定业务功能或需求，专注度高;

(2)系统容错率高，单服务的故障基本不影响整体系统运行，用户体验度

高;

(3)易扩展、可前后端分离，应对高并发、大流量的场景下可以快速扩容服

务节点增大吞吐;

（4）快速迭代、试错成本低，可以实现对业务的快速响应。

微服务技术架构包括网关、注册中心、配置中心、链路监控、流量控制等内

容，整体如下:

图：微服务框架

(1)服务集群，根据业务功能模块拆分成一个个独自的项目，每个项目完

成独自的功能，每个项目又称为独自的服务，每个服务构成了一个服务集群；

(2)注册中心，应用系统拆分成多个服务之后，每个服务都有独立的服务

信息(IP地址、端口以及功能等)，如何让对方知悉服务信息，需要注括中

心模块对服务进行整休管理。每个服务在注册中心中注册，当用户进行调用服

务，它首先到注册中心拉取服务信息再去调用相对于的服务。

(3)负载均衡，多个服务组成服务集群，在进行服务调用是通过负载均衡分

担服务调用流量，实现服务高可用的同时也增加服务的并发吞吐。

(4)网关，拆分成多个服务之后，涉及到服务之间的调用，一个服务调用了

三个服务的模块，在这个服务里，配置三个调用地址，看起来是不是很麻烦？

所以就出现了网关，麻有的服务调用都调用到网关，然后在网关里配置路由，

进行服务的转发，类似于代理的作用。当然网关需要配合注册中心进行使民，

去发现转发到哪个服务上去。是为了校验身份和清求路由，负载均衡。

（5）置中心，每个服务都会有各自的置信息，便于统一管理，使用到

置中心，如果想更改服务的置中心，就在置中心上进行更改，置中心

会通知相关的服务实现置的日更新。

除上述5大基础组件外，微服务还包括链路监控、流量