在路上：严选服务治理实践

当你面对一个由几百上千个服务高度耦合而成的大型系统，各式各样的问题便会不约而至，并且绝对是一个不小的挑战。熵增原理告诉咱们——任何系统都须要治理，本文分享严选在多年的服务治理实践中的一些思考、一些心得。

服务须要治理吗？

> 固然须要，你100%会碰上各类需求，各类问题。

古代的农民耕种最关心的问题是气候变化、按时播种、按量灌溉，而现在的现代化规模化种植时代，农民（和粮食集团）还须要去关注一系列其它问题，譬如多做物立体种植、经济效应最大化、环保合规和生态破坏等等。只要生产方式和生产规模不是一成不变，那迟早都会有新的问题诞生。

计算机应用亦然。当服务技术架构仍是单体服务（monolithic）的年代咱们须要解决问题A、问题B和问题C，到了MVC架构/RPC架构/SOA架构盛行的时代可能会引入问题D、E、F，当业务规模持续扩张促使架构演进到微服务（microservice）阶段，此时你会发现，可能老问题A、B、D、F消失不见了，但C和E依然存在，同时还引入了好几个新问题G、H、I、J和K。

> 存在问题或可能出现问题，所以才须要治理。

IBM在2006年对服务治理的要点作过总结，“问题”能够概括为如下10个方面：

1. 服务定义 Service definition：关注服务的范围、接口和边界

2. 服务生命周期 Service deployment life cycle：从规划到下线整个生命周期各个阶段

3. 服务版本治理 Service versioning：强调兼容性，新需求催生新版本，但迭代不能中断用户体验

4. 服务迁移 Service migration：启用和退役

5. 服务注册中心 Service registries：依赖关系

6. 服务消息模型 Service message model：规范数据模型

7. 服务监控 Service monitoring：异常发现、排障定位与恢复，强调SLA

8. 服务全部权 Service ownership：企业组织，用户角色，对齐服务与业务关系

9. 服务测试 Service testing：充分测试和验证，覆盖，重复

10. 服务安全 Service security：圈定保护范围，控制数据获取渠道并强化

在严选的实践中，咱们发现服务元数据管理（配置中心或叫CMDB）、注册与发现、流量管理、容量管理、资源调度、可观测性、故障定位、安全控制、平台抽象化等方面是解决问题的重中之重。同时，要重视规范流程先行、交付效率&交付质量和治理平台易用性。其实，这里面每个方面都很庞大和复杂，值得深刻钻研，它们都属于服务治理的范畴，整个服务治理就是“企业为了确保事情顺利完成而实施的过程”（SOA governance —— Anne Thomas Manes）。

 

若是你的系统规模很小，只有十几个服务，那治理成本是很低的，任何粗放式、人工式手段一般都能被接受。然而，当你面对一个由几百上千个服务高度耦合而成的大型系统，各式各样的问题便会不约而至，并且绝对是一个不小的挑战。熵增原理告诉咱们——任何系统都须要治理，假如咱们选择无视这些问题，则可能致使一些更加不可接受的问题，譬如维护成本剧增、规范腐化、MTTR增长、SLA降低、系统失控等等。

一句话，服务治理，势在必行，宜早不宜迟。

服务如何治理？

> 参考答案：拥抱DevOps。

DevOps是服务治理的好伙伴。DevOps落地让团队得到CMDB、CI/CD、CloudNative、ServiceMesh、Monitor等多重利器，为服务治理提供各类工具，是不可或缺的治理能力层。

严选DevOps工具链的持续建设让产技部门在效能、性能、稳定性等方面尝到了愈来愈多的甜头，随着基建愈来愈完善，服务治理情况也获得极大改善。正所谓内功外功要兼修，在这个过程当中，咱们发现服务治理很须要一个统一的易用的门户平台，不然开发、测试和运维都要去接触不少概念术语和底层系统，面临着巨大学习成本和上手门槛（效能↓），以及不小的出错概率（风险↑）。

因而，一个严选服务治理门户便水到渠成地诞生了，项目代号是服务鸟巢Service Nest，内部平常简称为SNest。前面提到服务治理要解决10个方面的问题，这些问题在背后会由不一样的系统在提供解决方案（如CMDB、Consul、Istio、KVM、K8S等），这些统统能够视为能力层，而SNest最大的使命就是包装所有能力层并统一暴露出来，做为服务治理的整合平台和用户端门户系统。

下面举几个例子。

服务元数据管理

服务类型、所属产品、不一样环境的实例信息（IP、端口）、JVM配置、Tomcat参数、操做系统特殊需求、服务的负责人/研发人员/测试人员列表等等，这些均可以视为服务的元数据，它们很是重要。

之前：散落在各地（开发和运维手上各自维护一部分，可能记录在一些内部零散系统或者wiki、甚至靠脑子记忆），有变动靠人工交流、手动执行，系统之间也无打通关联。可想而知，沟通成本巨大，并且，时间久了就意味着文档老化和数据变脏。

现状&规划：基础配置项（Configuration Item，CI）维护在严选CMDB，服务级别的配置项（也是CI）则维护在严选SNest，核心配置的修改由流程控制（严选工单），配置变动后触发通知（严选事件消息中心），再结合SNest提供的丰富OpenAPI，使得严选全服务的元数据得以平台化（入口收敛，规范落地于此）、流程化（变动审批和事件推送）、自动化（工单自动执行）和数据打通（系统间联动，通传通识）。对未来来讲，拥有完善的服务元数据对单元化和服务定义（Application Definition）等进阶项目都有极大帮助。

服务容量与资源调度

服务实例必须运行在必定资源之上，服务A可能须要4台8core/16G mem/150G HDD规格的虚拟机，服务B可能须要10台Dell R740物理机，服务A但愿不要与服务BCD共处同一台物理宿主机（这4个服务容易存在资源抢占，严选内部常称之为互斥），服务E但愿优先被调度到能提供SRIOV高性能网络的机器（云计算建德机房，特殊网卡+内核参数）上运行。与此同时，严选当前正处于上云过程当中，云内和云外两地机房的IaaS资源层实现是不一样的，云外机房跑的是物理机和KVM虚拟机，而云内机房跑的是云计算轻舟提供的K8S容器。

之前：仅提供少数几个规格备选，粒度粗，存在浪费（服务一般会偏大选择，主机利用率低），支持最简单的调度算法。主机利用率抓得不严，容量趋势预估多为人工，规格选择也是依靠申请人经验。

现状&规划：SNest提供多种丰富的细粒度规格，以及规格智能推荐、规格/副本数环境限制等策略，而且支持用户表达资源调度倾向性：云外使用WebKvm新算法和新表达式，云内则借助K8s Lable/NodeSelector/Toleration等对象来组合亲和性表达式。借助主机利用率统计和资源密集型定性，能够支持错峰调度，错开资源密集型调度，进一步提升总体利用率和降本。

服务注册发现与流量调配

服务注册发现与流量调配，这是ServiceMesh关键落脚点，包括一个服务在各个环境有哪些实例，运行在何处（IP：Port），处于什么状态（健康检测），但愿受理多少流量（流控频控），是否须要劫持流量作一些校验甚至篡改等等。严选的ServiceMesh架构一直在演进，云外机房使用的解决方案是Consul+Consul-Nginx，而云内机房则使用K8S+Istio云原生定制加强方案。

之前：服务注册走工单人工执行，平常可以使用一个老旧平台去维护实例状态，用户直接打Consul weight标签来控制每一个实例的流量（此时需人工核算每一个实例的weight值，容易算错），严选上云初期服务要切一部分流量进去云内很麻烦，必须找运维人工修改Consul配置和网关配置。

现状&规划：SNest抽象掉两地机房底层不一样的ServiceMesh解决方案并统一封装成接口，再以一个的简单易用的交互界面暴露出来，开发/测试/运维能够无需关心Consul/Consul-Nginx/k8s svc/ingress/egress/Istio RR,DR等专业术语有什么特性、何时用、何时不要用、有什么易踩的坑。用户在申请资源时SNest会自动完成服务注册（不管云内云外），平常管控时能够傻瓜式一键调配流量（控制各个机房分别受理多少比例的流量，或者每一个实例受理多少）。因为Istio能力很强大（它劫持了所有进&出调用），那么实现限流熔断、黑白名单、故障注入等也都是垂手可得，对应用无侵入。

严选的治理心得

严选的服务治理方兴未艾，诸多规划点都处于持续建设的状态，尽管距离终点还有很长一段路，但多年的实践经验仍是给了咱们一些思考、一些心得。

能力层要夯实

• 万丈高楼起于垒土，积基树本；

• 不管是CMDB层、MetaData层、IaaS层、ServiceMesh层、Monitor层等，它们都是服务治理必须依赖的基础能力，务必规划先行，规范先行，能力先行。这些能力层缺一不可，并且无一不重要，怎么样作好都不过度。

平台层要统一

• 能力层位于底层，并且多是异构的（不一样数据中心有不一样的实现方案），服务治理必须封装一个平台层：把底层抽象掉，为上层管控提供接口；

• 平台层能够实现收口，同时落地规范。从此能力层有进化，规范有调整，只须要迭代平台层便可；

• 也可让能力和规范都汇集起来，再也不散落，再也不失控。

交互层要友好

• 关键词是“友好”二字；

• 服务治理解决方案在面向用户（研发/测试/运维等技术人员）时必定要提供足够友好的交互门户，包括但不限于页面UI、工单流、消息通知机制等等；

• 越友好，越全面，越直观，越精细，越智能，这样的门户不只能够提升生产效率，还能下降上手门槛和出错几率。

演进要果敢

• 业务在发展，会提出更多新需求和新问题；

• 社区在演进，会提供更多新工具和新创意；

• 银弹是不存在的，当你察觉到治理现状对新需求和新问题已经显得捉襟见肘、无能为力时，你就应该果断启动新方案的研发和试点。业务那边不用太担忧，当前版本还在继续跑着，只需无感式地迭代你的“能力层/平台层/交互层”并适时推出新版本便可。至于老系统和老版本，该退役的就勿过于留念。从1到1.1也是创新。

小结

服务治理要解决十大类问题，仍是那句话，每一类问题单拎出来都是一个大型课题，都须要充分实践，并且没有一成不变的最佳实践。本文是严选在服务治理历程上的一些心得总结，权当抛砖引玉，望你们不吝勘正，发表评论和文章分享本身的经验。

路漫漫其修远兮，吾将上下而求索。

 

做者简介

书技， 网易严选运维SRE负责人，专一系统容量与稳定、DevOps效能、服务治理、线上质量等体系的搭建和发展。

 

招聘信息

严选基础技术团队正在招聘资深Java研发工程师、资深网络研发工程师、资深测试开发工程师。欢迎各位小伙伴加入，一块儿探索业务中台、服务网格、DevOps等技术方向，共同面对产品质量、系统稳定性、效率瓶颈等挑战，助力业务快速创新迭代和研发效能升级。

👇点击左下「阅读原文」，查看团队详细招聘信息。

 

本文由做者受权严选技术产品团队发布

 

 

 

本文分享自微信公众号 - 严选技术产品团队（YanxuanTechProd）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。