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

?

?

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

?

?

【导读】微服务是企业应用及数据变革升级的利器，也是数字化转型及运营不可或缺的助产工具，企业云原生更离不开微服务，同时云原生的既要最大化发挥微服务的价值，也要最大化弥补微服务的缺陷。本文梳理了微服务基础设施组件、服务网格、微服务技术框架知识，并提出了框架选择建议以及微服务的缺点及难题。

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大基础组件外，微服务还包括链路监控、流量控制（限流、熔断、降级）、日志管理、以及常用的中间件服务（文件、缓存、消息队列等）和服务网格等。

链路监控是实现云原生可观测性的方式之一，应用系统微服务拆分后，服务之间相互调用，前台页面的一个请求往往涉及后端多个服务的调用实现，复杂的调用及实现方式造就了一些列的问题，如：问题定位缓慢、故障影响范围不清以及服务依赖不合理等问题，同时服务调用的性能和实时容量也存在不清晰的地方，相关指标如服务吞吐量TPS、服务响应时间、服务调用失败率等难以量化。通过全链路监控从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。有了全链路监控工具，