【云驻共创】如何使微服务更加便利

近些年微服务大行其道，许多开发者为了微服务而微服务，没有考虑实际业务场景，只是为了追求技术热点，盲目引入微服务，但又缺乏相应的技术掌控能力，最后影响了业务的稳定性。

微服务是在互联网的发展中，大型公司开始面临单体架构的局限的情况下诞生的。微服务让部署服务器和管理基础设施的工作变得非常容易。很快，一个围绕微服务的产业发展壮大起来，它逐渐成为寻求扩展的企业默认架构。不幸的是，现在有许多公司由于这种选择而掉进了各种之前想不到的坑里。

下图是2015年到2021的百度搜索指数，微服务急速上升，然后开始趋于平缓。

微服务是在互联网的发展中，大型公司开始面临单体架构的局限的情况下诞生的，并非所有的项目都适用于微服务，就算是适用于微服务的项目，是否又可以很好的使用的微服务吗？今天就来谈一谈华为云在使用微服务的时候，是如何处理微服务在实际开发中遇到的一些问题。

1：如何更快的交付新的云服务

1.1：仅仅是注册发现吗？

上图是一个简单的注册发现过程，注册发现的真的是在做一个注册发现吗？其实并不是的，我们需要一些其他的信息，可以帮助我们在管理微服务的时候能够更加的高效。注册发现应该承担的更多职责，增加更多手段，可以技术管理者提供反馈。

首先我们在注册微服务的时候，每一个微服务的实例会有很多的信息，会有版本号、微服务名、环境信息以及服务框架。这些我们都会注册上来，最终发现是一个实例的IP和端口号。作为一个程序来说我们其实不太关心，更多人来关心的信息。所以说如果我们需要高效的管理服务的话，我们先要返回一个实体分离，分成一个基本不变的静态信息与经常会变化的动态信息，从而能够让我们的微服务更快的拉起。

图 1静态信息

图 2动态信息

1.2：服务的依赖应该如何管理

在开发微服务的功能中，我们很难管理架构，可能会出现服务重复调用和循环依赖，会增加项目的复杂度，导致项目很难去升级。

针对这个问题，我们可以采用审视依赖方向，按需推送实例变化，实时监控架构的依赖情况。

图 3服务依赖管理

1.3：为什么应用API first

在微服务开发的过程中，架构师设计了一些api能力，却不会去描述api能力。一般都是由开发去完成的，所以很难去管控开发所写的api。

当我们的系统变成微服务的时候，微服务A依赖微服务B，在微服务B没有完成前，微服务A很难开始。所以我们通过注册到ServiceComb的API生成mock代码进行集成测试。等到服务发布后，再切换到真实服务进行测试。应该可以在本地进行复杂分布式系统的测试，从而达到提升研发质量。

总结，通过静态与动态信息分离，服务依赖管理，应用API first，可以给架构师提供一个审视视角，

例如，可以帮助架构师规划合理的API设计，依赖关系；规范微服务元数据，防止滥用字段和冗余数据 ；提供可靠的注册发现等。

2：远远不止交付业务功能

图 4 冰山之下

在日常开发中这些非业务逻辑也占用了很大的工作量，我们采用了ServiceCenter的层叠架构，来减少工作量。

图 5 ServiceCenter架构

ServiceCenter架构包含了一下

1. 服务注册发现：通过注册发现完成 服务拓扑的感知
2. 契约发现：每个服务具备一个契约 记录，支持多种格式如Open API， gRPC proto
3. RBAC：基于角色的访问控制，管 理员可以管理账号，将账号分发给 微服务或者不同人员
4. 服务治理：针对微服务下发治理规 则，比如重试，限流，熔断，路由 策略等

2.1如何进行不同交付局点，不同代码分支交付

当我们面对产品定制化交付的时候，开发人员为了满足不同客户之间的差异需求,创建了很多分支，来交付不同的客户。如果有更多的客户，仅靠分支管理，是无法完成定制化交付的。我们可以通过以下几点来完成这项工作。

2.1.1 将后端服务作为插件使用

常见的后端服务基本配额管理，认证鉴权服务，对象存储服务。那是如何实现插件机制的呢？

• 定义后端接口
• 定义插件集，提供安装API

2.2.2 沉淀需求基线

为什么要沉淀需求基线？所谓的基线就是必须要实现的东西。因为这些需求在每个不同的项目中都是必须要满足的。

例如：

• 请求体必须做大小限制
• API必须限流
• 密码不能明文存储
• 访问进行认证鉴权
• 无单点故障
• 访问审计
• 运维能力

当你发现公司内部不同 部门都在开发自己的协议做自己的服务治理时，再向将业务统一一个架构，一个工具链上，将非常困难。所以我们需要一个标准化运行时模型，因为不同部门可能有私有协议诉求，那么服务治理就交给核心框架完成。协议由业务部门决定自主研发或是集成现有协议。

图 6标准化运行时模型

2.2.3 配置管理

在微服务项目中我们另外一个重点就是配置管理，我们实现了一个轻量级框架Go chassis，Go chassis可以远端管理：生产环境；本地管理：集尘测试；内存管理：UT测试。

图 7Go Chassis

2.2.4 易处理

微服务的几大要素里，其中一个就是易处理。基本含义，快速启动和优雅终止可最大化健壮性。 该要素原则体现到微服务应用有三点实践： 微服务启动时可以同时并发多个线程，采用懒加载方式，这样实现快速启动。 微服务终止是检查所有资源都是否销毁，所有监听都要关闭，释放所有的资源，最后什么也不留下地离开。 当非正常结束时，微服务自动恢复到默认状态上。

协议服务管理:

1:统一Server模型

2:通过配置进行协议服务管理。

优雅停机过程：

1. 停止心跳
2. 注销实例
3. 中断端口监听
4. 处理所有请求后退出

自定停机过程：

1. 停机前后可以定制逻辑
2. 可以彻底劫持go chassis原本停机过程
3. 可以替换默认的系统信号

http的优雅停机实现：

2.2.5 轻量级内核

下图是目前开源三方件依赖数量最少的工程，那我们的依赖都去了哪里？通过按需使用扩展能力和插件和定制的加载过程，来减少依赖。

图 8go.mod

在go-chassis-extension工程，按需使用扩展能力和插件 。

在bootstrap中，可定制的加载过程

3：云原生生态构建

在生态上我们也做了一些自己的工作，例如在spring cloud上也做了一些扩展。

例如：

• 利用开源，只做扩展，不做封装：保持原生spring cloud代码写法，并做特性增强
• 增强注册发现：提供文档管理，编写一份spring cloud 代码即可自动生成并上传到服务中心
• 路由管理：自定义规则完成金丝雀发布，蓝绿发布
• 增强配置管理：原生注解，接入到自研配置管理，提供配置一键回滚，历史管理，推送轨迹等高级特性

3.1该不该用SideCar模式？

将应用程序的组件部署到单独的进程或容器中，以提供隔离和封装。此模式还可以使应用程序由异构组件和技术组成。这种模式被称为Sidecar，因为它类似于连接到摩托车的边车。在该模式中，边车附加到父应用程序并为应用程序提供支持功能。 sidecar还与父应用程序共享相同的生命周期，与父项一起创建和退役。边车图案有时被称为搭接图案并且是分解图案。

1：负载均衡、通用指标监控，路由管理等能力“卸载”到服务网格，适合自己业务的才是最好的 。

2： 卸载后，应用仍需要一个云原生开发框架，来提升团队效能，除了异构系统对接，还有业务指标，优雅停机，配置治 理等云原生需要满足的能力，微服务框架可能会逐渐演进为轻量级框架或者说叫“云应用框架” 。

3： 过分的市场热度和吹捧，对最终用户是一种伤害，技术是拿来用的，不是讲出来的。

4：案例

4.1案例一（华为网管产品）

• 快速管理华为和三方设备
• 设备配置能力开放

4.2案例二（实时音视频 RTC）

• 华为荣耀手机和智慧屏等终端的视频通话后台
• 已独立上线公有云，支撑终端公司畅联通话上亿注册用户，基于go-chassis进行服务治理。

产品页面：https://www.huaweicloud.com/product/rtc.html

4.3案例三（边缘计算KubeEdge）

• 基于go chassis开发服务治理底座
• 管理着全国29个省、自治区的将近10万边缘节点，超过50万边缘应用的部署。支撑了1万多个收费站中门架信息采集业务的不断调整、更新，满足了每日3亿条以上的信息采集。
• 为日后车路协同、自动驾驶等创新业务的发展提供了良好的平台支撑

Git地址：https://github.com/kubeedge/kubeedge

4.4案例四（某框架二次封装）

本文整理自华为云社区内容共创活动第二期之【线下分享】华为云的微服务实践。

查看活动详情：https://bbs.huaweicloud.com/forum/thread-111494-1-1.html