在容器云上部署微服务，如何实现微服务治理？

Posted 2021-04-25 twt企业IT社区

原题：《容器云之微服务治理》

服务治理是SOA的一项重要内容，是为了确保SOA采用和顺利实施而采用的标准、规范、流程、方法、原则、工具、模型、实践经验等，是保证服务化实施成功和持续改进的关键。微服务通常我们也归于SOA架构，也可以借用SOA服务治理的理论和实践经验，来确保微服务实施的成功。

服务治理通常会要求组织架构的调整，建立治理委员会，这也说明服务治理的重要性。另外如果微服务部署到容器云，又该怎样和容器云结合来实现微服务的治理？这是我们面对的很关键的问题。

IT需要有全局性和前瞻性，那服务治理也是一样。

一、服务治理和服务管理

治理和管理有什么区别？治理属于管理范畴还是治理包含管理？服务治理和服务管理是什么样的关系？争论也很多，就像数据治理和数据管理一样，没有一个标准答案。管理的外延更广，借用数据管理和数据治理的一种划分方式，我们可以把服务治理归于服务管理之下，作为服务管理的一个方面，服务管理可能还包括服务生命周期管理、服务资源管理、服务质量管理、服务运营管理等。管理和治理很难划分的很清楚，它们相互融合相辅相成。我们的理解是管理可以认为更多是一些行政性的工作，治理更多是强制性标准化、规范化的工作流程。

二、容器云上微服务治理需求

微服务相对于SOA ESB来说更灵活，但越灵活的架构方案面临着越大的挑战。随着服务数量的增长，服务生命周期的管理、资源的分配、不同服务质量需求的保证、服务日常运营等工作将会耗费越来越多的精力，带来巨大的压力。微服务架构应用非常适合容器上部署，容器化又会带来服务实例数的加倍增长，超出了人力所能管理的范围，所以也就有人引入了DevOps，通过工具、方法论、标准化规范化流程等来协助实现微服务的管理需求。

容器云、微服务、DevOps理论上倒是一组很完美的组合。但目前还没有真正的落地，大部分项目也仅仅是在验证实验阶段。服务治理往往要求相应的组织架构调整，这在非IT为中心的传统行业基本上等于痴人说梦。IT往往被视为辅助部门和手段，从思想上还未真正认识到IT技术作为第一生产力的能力，另外，这些行业IT从业人员的整体技能也欠缺。云计算带来了很好的机遇，不仅仅是提供了更多选择，降低了成本，更有不少公司实现了弯道超车。数据放公有云不放心，容器化私有云成了一个比较好的选择。在容器云上部署微服务，企业内部实现DevOps，治理的思想就不可或缺。

采用云计算的多租户思想来替代组织架构调整要求，是我们的一个现实的思路。云计算化大为小，一个公司的治理组织架构也可以通过多租户化大为小。租户方式避免做出大的调整，可以快速的适应新技术的采用，更多的是形成一种意识和习惯，这也是我们提倡的DevOps思想。

服务治理涉及的内容很多，结合容器云提供的能力，采用DevOps的思想，实现应用服务的全生命周期管理和治理，是我们潜在的需求。服务的注册发现、配置、监控、访问控制、负载均衡、路由、限流、过滤、熔断等都是需要考虑的需求。基于我们ESB的服务治理和管理的经验，以及对容器云、DevOps的理解、微服务架构的设计，提出了下面容器云上微服务的治理方案。

三、容器云服务治理方案

容器云微服务治理方案根据微服务的架构分为数据层、服务层和应用层。数据层支持不同的数据存储方式和数据集成方式，通过服务层来统一向外提供标准的接口微服务；根据业务需求来使用微服务实现业务应用服务；应用采用Client /Server前后端的方式实现，所有应用的请求通过API Gateway集群分发到相应的业务应用服务上。API网关层同时提供API管理能力、API访问控制能力、负载均衡能力、路由、容错、过滤、映射转换、限流、熔断等，以及结合容器云的多租户管理能力，实现服务的分类管理和权限管理等。为了支撑微服务架构，实现服务注册发现机制、提供服务配置能力、服务日志记录能力、服务运行监控和告警能力以及服务访问统一认证、单点登录能力等；在服务的开发、运营等整个生命周期过程中遇到的问题、需求等持续反馈到DevOps中心，并持续的改进这些应用服务，以更好的满足实际业务需求。

四、业务应用

应用前端：应用前端可以是Web、手机、App、小程序等等，是展示给用户所能提供的业务功能及和用户交互的渠道。应用前端和业务服务共同来实现业务应用。

业务服务： 基于公司实际业务的需要来实现业务服务，复杂的业务逻辑通常在这一层来实现。它调用微服务或者也集成复杂事件处理系统，共同完成业务处理需求。

微服务：微服务层是采用微服务架构实现的服务，更多像是我们在ESB中的原子服务称谓。这些服务供不同的部门、团队来使用和构建业务应用系统。通过租户机制来实现资源隔离和服务的权限管理。

数据层： 数据层讨论的是微服务的数据源，数据源不仅仅是数据库，可以是数据文件、大数据系统、应用系统、消息、缓存数据等。当然通常我们是使用数据库，所以我们在设计实现微服务的时候，通常也更多考虑的是分库分表等机制。但我们认为数据存储不仅仅是数据库，就像枚举值数据字典服务一样，可以把数据存储在文件中，启动时加载内存。

五、API网关

我们一直强调API网关的重要性，它是实现服务治理的一个主要工具。虽然现在也有很多服务开发框架和服务治理工具都提供一定的服务治理能力，比如SpringCloud、Dubbo、Istio等，但我们觉得这些框架和工具都有一些不足，另外基于自身技术实力的考虑，使用开源组件需要有较高的技术能力支持，需要能把控这些开源的组件，在出现意外情况下有能力解决。所以我们推荐使用传统的商用API管理工具和API网关来实现服务治理的一些主要能力。根据自身服务的平台和架构，实现相对完善的服务治理方案。

六、多租户

多租户机制是容器云平台实现组织架构隔离和服务管理治理的一种实现方式。每一个租户都可以看做是一个客户，即便是一个公司内部，“服务”的思想也要成为一种潜意识。每一个部门、每一个团队、每一个同事都是“服务”的对象。权限管理实现对服务访问的授权认证和访问控制。租户及权限管理实现了业务应用业务服务的资源隔离，使服务/应用生命周期管理更容易，职责也更清晰。

七、服务治理基础组件

1．注册发现中心

服务注册发现中心提供服务的注册和查询能力，服务开发出来需要注册到服务注册中心，就象人一生下来也要登记一样，注册后的服务就可以被其他用户来查找使用。当然注册发现机制可以是自动化的。

2． 服务配置中心

服务配置中心提供服务运行时的环境配置选项。越来越多的人认识到了分布式环境下服务配置中心的重要性，服务配置中心作为独立的一个基础组件被越来越多的人认同。它已成为分布式环境下服务治理的一个重要基础组件。

3． 服务日志、监控、告警中心

健康检查、运营监控、调用统计、运营分析、日志记录、预警告警等是服务服务日志中心、监控中心、告警中心需要提供的能力。自动化的日志、监控、告警、分析能力是业务应用服务正常运行的保障，也是提升效率、降低成本、实现标准化流程的手段。

4． 任务调度中心

任务调度中心提供定时任务、批量任务的调度管理。任务调度不涉及资源的调度管理，只是应用服务层的任务调度实现。资源调度管理交给容器云平台去实现。

5． 安全中心

任何时候安全都是重中之重，安全中心提供权限管理、访问控制、单点登录、统一认证、授权准入等安全机制。前面我们也讨论过，分布式应用的发展就是组件服务化，权限、认证、单点登录等公用的组件需要提取出来作为公共的服务，来支撑一个企业所有的业务应用，而不是每个业务应用都搭建自己独立的权限、认证组件。

6．负载均衡

分布式化使单一的组件或服务不能满足业务请求处理需求，这就需要建立组件或服务的集群，来共同支撑业务请求需求。负载均衡机制平均分发请求到集群中的每个组件或服务，从而可以实现组件和服务的动态伸缩，来支撑业务请求的动态变化。

八、服务请求预处理

除了服务治理的必须的基础组件外，通常请求在被业务服务处理前需要做一些预处理，比如路由分发、请求过滤、数据转换、请求限制、阻断请求、异常容错处理等，这些能力通常可以在网关层实现，也可以在服务层实现。但是从服务治理标准化、规范化等方面讲我们觉得在网关层实现会更好些。

1.路由

路由实现分发请求到不同的服务或不同版本的服务实例上。API网关层实现首次的请求分发，基于服务的架构，一个请求也可能经过不同层实现的多次的路由才被处理。

2.过滤

过滤实现对不合法请求的拦截，只放行满足规则要求的请求。比如未授权访问、黑名单、反爬虫等规则可以在这里配置。

3.转换/映射

对外的API可能和内部的API不同，比如内部提供的是JMS API，在网关层映射为HTTP restful API对外公开，请求在网关层需要转换。也包括字段类型转换、名称映射，甚至可以有计算和编排逻辑。

4.限流

在资源利用率达到极限的情况下可能不得不考虑限流。容器云平台虽然有弹性伸缩的能力，但资源总是有限的，不可能实现无限伸展。特别遇到网络攻击时，限制入口流量使一些请求超时，避免使整个系统受到影响。

5.熔断

熔断和限流一样，同样是一种保护机制。在服务或者网络出现故障的时候，为了防止故障影响到其他服务的正常运行，阻断该服务的请求，或者采用容错机制来保证服务不受影响。

6.容错

容错能力保证在一个服务实例故障时，请求能被其他服务实例正常的处理而不受影响。我们追求的是尽可能的降低容错率，虽然不能保证不出错误，但在规划设计实现时尽可能的考虑如何降低容错率。

九、服务生命周期治理

服务整个生命周期管理和治理包括服务计划、研发、测试、部署、发布、运营、下线等整个过程。在容器云平台，通常计划、研发、测试阶段的治理和管理可以通过CI流程结合DevOps方法论来实现。我们更多关注的部署、发布、运营阶段，通过容器云平台提供的灰度发布、弹性伸缩、负载均衡、租户管理等能力和DevOps方法论来实现。

1.灰度发布

结合流量控制、路由等机制来实现新发布版本的验证功能。避免有重大缺陷而导致用户体验的感觉不好。

2.弹性伸缩

应对突发请求的支持，容器云虽然提供基于CPU、Memory资源使用的弹性伸缩策略，但不足以满足实际业务弹性伸缩的需求。这在微服务架构设计时需要考虑，如何使用采用的平台和技术来更好的实现弹性伸缩。我们在前面《容器云之弹性伸缩》也讨论过。

3.服务编排

微服务需要编排成业务服务，提供业务应用给客户使用。《容器云之服务编排设计》中我们讨论过。

4.服务SLA/服务质量

服务SLA/服务质量是服务的评判指标，也是服务治理的重要内容。一个服务的能力，响应速度、并发处理能力、可靠性、可用性等需要满足相应的指标。比如响应时间，是微秒、毫秒、秒级还是分钟级；以及和负载的关系，负载增加，响应时间的变化趋势是什么。

5.优先级/服务降级

服务优先级或服务降级措施是为了保证重要的服务在负载大的情况下能优先处理其请求。比如日志等不是关键业务的请求可以晚些处理。一般结合缓存、消息机制来实现。

6.资源隔离

容器云平台首先从租户实现了资源分配和隔离，服务和应用也不可能无限扩展，需要实现资源的限额和隔离。比如网络资源，不同应用可能需要实现网络隔离，禁止应用之间的访问。

7.软负载均衡

负载均衡可以在多个层次来实现，比如使用消息组件来实现消息的负载均衡处理，使用nginx实现http等请求的负载均衡等。基于服务的架构来选择合适的实现方式。

8.持续反馈

治理的目的就是通过不断的反馈来持续改进服务、流程、标准、规范、模型等来更好的满足业务发展的需求。没有什么是一成不变的。我们采用DevOps的目的也是为了适应这样的变化，协调团队、人员、任务之间的关系，使之更好的服务于公司的发展需求。

十、DevOps中心

服务治理可以看做是DevOps的一部分。DevOps中心不是一个部门或一个团队，是所有参与的人员、标准、规范、流程的集合。可以看作是一个虚拟的团队，由来自各个团队的技术架构师、业务架构师、数据架构师、安全架构师、项目经理、团队管理人员等来共同领导和保证服务整个生命周期的正常运行。DevOps中心不断的收到服务生命周期各个阶段的监控反馈，在这些反馈信息的基础上持续的改进，这既是服务化服务成熟度模型的要求，也是业务不断变化满足业务需求的要求。

从来没有完美的技术、完美的方案，理想和现实总是有距离的。治理也是一样。不敢尝试就不会有创新。熟能生巧，在实践中不断的完善，不断的创新，才是成长和发展之道，才是持续改进的要求。

作者文章：

更多相关文章，请点击阅读原文