谈谈如何构建企业级微服务架构

1.企业级微服务架构的定义

企业级微服务架构是具有一套完善的软件生产流程、资源管理机制和风险管控体系的微服务架构平台。它的本质是将所有的编程资源服务化为可编程接口，为应用的开发和运行维护提供通用、快捷、稳定的基础支撑能力。它能够整合所有技术组件，协同工作；能够协同开发和运维，实现软件自动化交付；能够提供容器化封装和服务编排，实现资源共享和弹性伸缩；能够提供系统监控，实现故障自测和自我修复，提供快速定位问题能力；同时还具备大数据分析能力，为系统运营的持续改进提供帮助。

2.企业级微服务架构必备能力分析

企业级微服务架构要具有一套完善的软件生产流程、资源管理机制和风险管控体系，不但要满足日常软件交付，还要能实现资源的弹性伸缩、系统的风险管控和业务的持续运营。这是因为微服务架构带来的分布式系统的复杂性已经超过人工的能力范围，所以需要一整套完善的保障机制来保障系统在人力可控范围内运行。

实施微服务的目的是增强系统的扩展能力和弹性伸缩能力，也就是系统的运营能力。谈到运营能力，要看系统的反应能力，面对新需求、业务变更的反应速度，在信息时代，唯快不破，所以，高效的软件交付也是企业级微服务架构的必备能力之一。

企业级微服务架构要具备一下能力，主要包括基于容器的应用托管、智能化系统运维、系统化业务运营三方面内容。

企业级微服务架构能力分布图

2.1 基于容器的应用托管

在传统开发模式中，系统要上线，开发人员提交代码，通过版本管理工具进行代码整合，运维人员把代码打包编译程一个个JAR包，然后进行集群部署。由于操作对象少，一起还在人为掌控中，而一旦实现微服务，一个系统被拆分成成百上千个微服务单元，人工部署将会捉襟见肘。

DevOps就是开发运维一体化，其核心是自动化协同。自动化是技术手段，通过纵向打通工具链，打通开发、测试、上线部署各个环节，实现自动化流水线部署。协同是横向打通部门隔阂，通过流水线把开发、测试及运维相关的所有人员协同起来，更高效的工作。

2.1.1 应用部署

应用托管平台继承了 Kubernetes 应用部署的便捷性，在控制台配置好应用的基本信息、部署资源域、扩缩容策略、 存储卷之后，部署人员只需要一键即可完成应用的部署。平台会自动按照容器编排的顺 序完成镜像拉取、容器创建、实例运行等工作。

2.1.2 故障自愈

故障自愈是副本控制器的一个具体应用，运维人员需要应用组件配置一定的副本数 （Replicas）来保证其服务能力。

2.1.3 优雅停机

当使用该命令停止容器时，容器内部运行的应用需要在 10 秒 （默认时延）内停止，如果超过该时延，该命令会继续发送 SIGKILL 的系统信号强行 Kill 掉进程，这时，该容器中运行的程序将被强行停止。

2.1.4 滚动升级

滚动升级指不停机升级，服务集群中的每个服务节点分批依次升级替换，在升级的 过程中不影响业务的正常使用。

2.2 智能化系统运维

智能化系统运维主要包括基础资源管理能力、有效的服务治理能力、调用链跟踪分析能力及预警、告警能力。

2.2.1 基础资源管理能力

基础资源指的是代码库、配置信息、容器、环境等资源，拆分成微服务后，代码库体积可能变化不大，但管理队形会增多，关系会变得复杂，运营指标也会不一样这些都需要有效的管理。配置信息涉及服务资源的分配，而服务数量众多，还要考虑资源动态分配，所以配置信息对于系统的稳定运行至关重要。容器与环境是微服务的基础，如果不能为自动化软件交付提供基础能力和实现系统资源的弹性伸缩，那么实施微服务就是一句空话。自动扩缩容指托管平台根据监控的应用运行指标自动进行应用的扩容和缩容，如在 服务负载超过设定阈值时，通过增加实例来降低已有实例的工作负载，实现系统的扩容； 而在服务负载降低至低阈值且达到持续时间之后，平台又会“杀掉”若干实例，来达到 缩容释放资源的目的。

2.2.2有效的服务治理能力

打造平台的稳定性是系统建设的永恒追求，特别是拆分微服务后，分布式系统固有复杂性带来了更多的故障潜在点和更难的问题排查，这就对系统的稳定性和可维护性提出了更高的要求。如果没有有效的服务治理手段，则系统就会陷入无序和不可控。所谓有效服务治理，就是系统要能够提供服务资产管理能力、在线服务控制能力，以及问题自动检测和主动自愈能力。服务注册与发现、熔断机制、限流与降级、流量调度、故障转移等都是打造平台稳定性的有效手段。

2.2.3 调用链跟踪分析能力

微服务架构解耦了业务系统，使得系统日志碎片化。如果还采用在单体模式下通过登陆后台主机查看日志的方式定位问题和分析则会变得非常困难，必须要有一种新的技术手段能够快速定位和分析问题。因此，调用链跟踪分析成为微服务架构的必备能力。调用链跟踪分析是通过汇集日志，把完成一项业务过程中的调用的所有服务根据先后顺序串接起来形成调用链。调用链跟踪除了展示服务的调用关系外，还要能够记录每个服务的执行状态、执行时长、运行态参数等信息，具备系统执行瓶颈分析、故障传到分析。运营指标分析和输出质量报表等能力。

2.2.4 预警、告警能力

预警告警也是一种保障系统稳定性的重要手段。预警是一种事前告警行为，通过设置安全阈值实现预警。告警则是一种事后告警行为，当系统出现问题，就发出告警，通知相关责任人。预警告警要能够根据告警的不同级别设定不同的默认处理方式，如容灾、容错、故障转移等。

2.2 系统化业务运营

支撑业务运营是系统价值所在。传统业务运营对系统要求不高，只要系统稳定运行，能够满足日常业务活动即可，高并发要求不高。当前信息社会下，随着人口红利的结束，个性的需求开始出现，系统也不再孤立，生态的快速发展，对系统的运营能力提出了更高要求，要求系统保证7x24小时不间断提供服务，还要集成各类能力，提供丰富的分析报表，运维团队正朝着从日常运维向运营职能转变。

微服务化的系统运营责任更加明确，每个团队负责各自的微服务，系统化业务运营要能够达到以下要求：

1. 能够评估微服务质量，与运维团队绩效挂钩；
2. 提供系统运营质量报告，包括服务调用次数、出错率、系统分布、价值、风险评估等内容；
3. 个性化需求的定制能力，根据用户个性化要求提供自定义的服务；
4. 构建生态的能力，对外提供OpenAPI；

3.实施企业级微服务架构的门槛

企业实施微服务架构是有前提的，并不是开源组件的简单堆砌，要构建微服务架构平台，要具备以下能力：

1. 计算资源的快速配置能力：微服务讲究的是独立不是、独立演进，这会涉及多个计算单元，这就要求计算单元配置必须是快速自动化和弹性伸缩；
2. 基本监控能力：微服务是一个复杂的工程，服务间协作处理一个请求，容易出现问题，而这些问题很难在测试环境被彻底发现，所以需要一个有效的监控机制来快速定位问题；
3. 应用快速部署能力：在微服务架构中，一个功能的变更涉及多个微服务，

4. 总结

微服务具有按业务能力组织服务和服务即产品的特征，我们会把一个大应用拆分成不同领域的系统，更倾向于让每个团队负责分配给自己的微服务的全部生命周期，所以每个微服务背后的小团队的组织是跨功能的，包含实现业务所需的全面技能，微服务负责制对个人能力要求更高，自驱动和自学习能力会让我们快速成长。借助企业级微服务架构，可搭建多渠道的中台系统，承载千万级 QPS 流量压力，提高整体资源的利用率和业务可靠性，并缩短了开发测试及部署流程，从而快速响应业务部门的各种新需求。

 

作者：闫振强

链接：移动云开发者社区

来源：移动云官网开发者社区