浅谈服务管理（一）

困局

        随着面向服务架构（SOA）以及微服务设计模式的兴起与流行，越来越多的技术公司投入到轰轰烈烈的系统升级改造的浪潮中，以换取更快交付软件、更快响应变化的能力。在这样的背景下，服务数量以始料未及的速度快速攀升，随之而来的就是带来了一系列的问题。

       当服务数量达到百万级的境况下，原本很多不凸显的问题忽然变得很凸显，原来感觉不是很制约效率的过程变得很费时费力。

        传统的服务管理很多情况下是采用Excel/Word文档来管理，服务数量可控的情况下这样的方式应付起来游刃有余，但是当服务越来越多、迭代越来越快、组织越来越复杂，忽然发现问题来了：首先，面临的是接口的编辑成本问题；其次，服务的共享、更新的时效、版本的管理的难度越来越高；不同的团队不同的文档风格，项目沟通、组织调整等等团队融合的过程增加了显性的沟通理解成本；作为服务提供者而言，服务变更后通知关联方的难度可想而知。由此时常引发不必要的生产问题。

 

        服务越来越独立，接口越来越多，但是该有的服务上下游依赖关系还是存在，常常出现联调过程中调用方需要被动等待服务方进展，当然也不是没有解决方案，打桩能够很好的应对这样的情况，但是如何减少打桩的成本、减少打桩对代码的侵入性、提高打桩的可复用性又是痛点颇多。

        版本迭代越来越快，服务变化越来越频繁，自动化测试案例的编辑维护成本以及功能测试投入的回归的成本越来越高。

        凡此种种引发了研发过程一连串的问题。

破局

        随着问题的凸显以及因此带来的各种不可控的研发过程以及生产问题，统一服务管理标准势在必行。

        显而易见，研发中的各类角色，包括项目管理、产品、架构、开发、测试对于服务管理的标准化、高效化、自动化诉求都是高度一致的，本着提高研发效能、辅助优化研发流程的价值目标，专业的服务管理平台级解决方案有利于突破上面描述的各类问题解决。

怎么开始？

        万事开头难，从何处着手解决问题，如何保证解决问题的思路和方案是正确的、保障成果是有效的，如何快速快速突破实现价值。那我们首先来分析下产生服务管理诉求的原因：

         随着领域驱动架构、持续交付、微服务架构的火热，越来越多的巨石架构应用被拆分为微服务架构应用，这种架构的优点很显而易见：易扩展、易部署、易开发、易独立测试，但是不足也随着产生：

- 为了保证服务的独立和解耦，服务被拆分的很多很细，数量众多；

- 系统间的调用链路非常复杂，集成调试困难；

- API风格多样：为适应不同场景的需求（封装性、服务契约、自治性、延迟、异常、消息编码），采用多样的API风格，常见的风格有RPC、REST、GraphQL、服务端驱动。

- 服务治理难度加大

服务管理面临的挑战

正如上面描述的这些问题，在当前的微服务架构模式之下，需要建立健全服务管理能力，那我们面临哪些挑战呢？

1. API接口文档编辑维护工作量大，经常升级维护；

2. 文档标准规范不统一，每个人输出的接口文档都不尽相同，后期沟通、维护会是很大的时间成本；

3. 检索查询困难，很多传统方式依赖文件系统管理服务，只能通过**ctrl+f**的形式来查询关键字，同时也不支持模糊检索、缩写等形式，服务越多越难查询；

4. 服务风格的多样性适配：RPC、REST、GraphQL、服务端驱动等多种类型的服务，如何提供便捷高效的管理支撑；

5. 服务版本的复杂度：多个版本的兼容/不兼容升级，如何有效管理；

6. 服务的依赖管理：面向服务架构的推行使得服务上下游依赖关系异常磅礴复杂，如何有效实现可视化管理；

7. 服务数据的时效性、有效性：高速的迭代下，如何识别服务契约是否已经失效，确保服务可用性；

8. 研发测试过程的支持：如何支撑快速迭代下的自动化测试能力。

面对这些挑战，我们如何打造服务管理能力呢？下面我们就来具体的聊一聊服务管理相关的解决思路。

服务管理的解决思路

1. 平台化：以系统/平台支持在线管理服务，更好的支撑共享和版本管理的诉求；

2. 可视化：以可视化的方式支撑报文的入参出参，使得结构更易于使用和理解；

3. 自动化：自我发现服务新增、变更、调用链路等信息，减少人工维护工作量的同时杜绝因服务升级导致的上下游系统问题；

4. 规范化：规范服务的生命周期管理；

5. 增值化：提供服务测试、mock能力，集成项目管理等能力，为塑造DevOps能力提供基础支撑。

浅谈服务管理（二）