网友提问：
微服务架构下，API如何治理？
优质回答：
个人理解首先要实现最基本的API全生命周期管理能力。
这个能力部分可以由API网关来提供，但是更多的还是要自己开放API的治理管控平台来实现。具体的API全生命周期管理包括了如下内容。
API接口的定义
在定义API接口的时候首先要定义API分组，这个从京东，淘宝等OpenAPI能力开放平台的API文档都可以看到，首先要有API归类分组，然后再定义详细的API。
比如京东开放平台，有商品，店铺，仓储，支付等多个类目，然后各类目下有详细的API的定义。
API的定义包括两个部分，一个是API基本信息定义，一个是详细输入输出定义。
API基本信息仍然是包括了API的编码，API名称，API的分组，API的用途描述，API的缓存，安全等基本控制信息的定义等。还有就是这个API接口的访问路径定义，API接口是Get还是Post方法定义等。
API详细信息主要就是API的输入和输出信息定义。
API的输入参数注意实际有多种形式，一个就是在API访问路径上的路径参数，还有一个就是在访问路径后？参数后面的查询参数信息，还有就是一个完整的Request Body请求参数信息。
比如对于Http Rest查询接口，这类Get方法接口，可以看到并没有Body信息，更多的是通过路径和查询参数定义来完成查询。而对于Post接口往往就涉及到具体的Body信息定义。
但是要注意，为了实现Http Rest接口和SOAP WS接口服务的互相转换，对于SOAP WS查询服务接口在自动转换为Http Rest接口服务的时候实际上仍然为转换为Post方法+Body参数模式。
对于API接口定义，仍需要预留标准的系统级参数部分内容。这部分内容是API网关实现统一标准化管理的基础，不能随便修改和变动。比如京东API平台预留的API名称，方法，版本，Token，APP_Key，Date等都是使用系统级别的参数定义，是每一个接口API暴露后都需要增加的参数头信息。
API快速开发的支持
在API接口服务定义完成后，一方面是可以通过类似WADL或RAML等标准的Rest接口定义规范文件，另外一个就是需要提供客户端和服务端的开发框架代码。
在这个基础上，还可以提供完整的示例代码下载，方便开发商或合作伙伴对API接口进行快速开发。开发完成的后端原始服务接口，在注册接入前还可以提供接口服务的模型匹配自校验功能，确认开发的服务完全遵循从上到下方式-》API开发框架生成和API后端服务开发。
对于API接口管理，如果是标准的从顶朝下模式，即在定义了API接口后，实现生成类似WADL或RAML标准接口规范。后端服务基于我们标准的API接口契约进行开发，那么开发完成后就方便快速X方式接入，在接入过程中就不再有参数映射和转换的问题，否则我们的API接入过程会比较复杂。
API接口服务的注册和接入
API接口定义过程和API接口的注册接入最好分开。
在API接口定义完成X行API接口服务的注册，即选择具体的后端服务，然后对服务进行接入。同时将后端服务对应到我们在前面定义的API接口X服务上。注意在前面谈到的API路径定义，方法类型定义，实际上也可以在API接口服务注册和接入的时候来完成。
API接口服务的后续变更发布，还可以考虑和DevOps平台配合并支持灰度发布功能。
反向的后端服务快速接入并发布为API接口服务，即直接对后端已有的API服务进行快速接入，将API后端服务发布为X服务，在整个接入过程中需要定义API接口名称，API访问路径，API方法类型等信息。在发布为API接口服务后，对于后端服务的API参数信息也需要进行快速导入，以方便在API接口查询中看到详细的接口内容定义。
在将后端业务服务发布为API接口服务的时候，发布的X服务要自动增加系统级的输入参数信息，这个输入参数最好的方式是在访问路径中进行增加，以减少对已有的后端服务的影响。
API接口在注册和接入完成后，将自动进行服务部署和服务发布，即注册接入完成后的服务可以通过发布的访问路径地址进行访问。
API接口在线模拟测试功能
这个功能参考当前的OpenAPI能力开放平台的做法来实现即可。即对于已经发布完成的API接口服务，提供在线测试工具进行在线测试。同时对接口服务调用的输入参数进行结构化展示，方便用户对测试需要的各种参数进行输入。在输入完成后形成完整的提交参数完整字符串。通过测试，可以返回最终的模拟调用返回结果字符串信息。
API接口查询功能
对于API接口查询功能也是一个标准的功能，实际上可以考虑将查询功能和API接口服务的分类浏览分开。对于API接口的分类浏览参考开放平台的API接口文档做法来实现接口。对于API接口查询，即可以设置不同的动态查询条件，对API接口进行查询，返回结果集。对于查询到的API接口清单列表，可以点击详细进入到API接口详细的输入和输出信息查看界面。
API状态管理功能
对于已经注册和发布的API接口可以对其状态进行管理。其中主要的状态包括了待发布，上线，暂停，下线废弃等几种关键状态。对于API状态本身还需要和后续的API监控管理结合，能够通过API性能监控动态的调整API接口的状态。比如在API触发熔断后，自动对API接口状态调整为暂停。
API版本管理能力
对于API需要启用版本管理能力。当前一些API接口服务实现方法会在路径参数中增加API版本信息，以确定究竟访问哪个版本。但是由于不同的API版本可能存在返回的结果集的数据结构不一样的问题，因此对于这种场景需要针对该API定义不同的大版本，不同的大版本实际上对应不同的后端原始服务。
当然对于API治理也可以参考SOA治理整体方法论，比如对于SOA治理我们给出过如下的治理管控框架，如下：
对于Oracle的SOA治理，为了实现业务、企业架构 和 SOA 目标，必须在不同业务领域制定策略：X结构、技术基础架构、信息、财务、组合、人员、项目（或项目的执行方式）和运营。其比较明显的特点是体现了EA企业架构，业务架构对SOA治理活动的影响和推动。而IBM的SOA 治理和管理方法（SOA Governance and Management Method，SGMM）是一种端到端的定义方法，通过设计、实现和改进 SOA 治理来进行。IBM的治理生命周期将治理活动分为了计划，定义，使能和度量四个阶段，涉及到服务生命周期各个方面的内容，具体如下：
服务定义，包括服务的范围、接口和边界
服务部署生命周期
服务版本治理，包括兼容性
服务迁移， 包括弃用和退役
服务注册中心，包括依赖关系
服务消息模型，包括规范数据模型
服务监视，包括进行问题确定
服务所有权，包括合作组织
服务测试，包括重复测试
服务安全， 包括可接受的保护范围
对于Oracle和IBM的治理进行对比分析，不断发现存在的一些相同点。从方法上看都覆盖了传统的项目管理，SOA服务工程框架，ITIL运维管理三个方面的内容。从范围上看则包括了组织人员，业务技术和管理三个方面的内容。而从流程上面可以讲是覆盖了服务全生命周期，包括服务识别发现，定义设计，开发测试，上线的前生命周期，也包括了服务开通，运维，监控的后生命周期。基于以上分析，可以看到SOA治理是一个覆盖服务全生命周期，涉及业务域，服务域和支撑过程域三个方面内容的完整治理框架和模型。如上图所描述一样，通过这种二维的结构，基本上可以看到SOA治理和管控所涉及的全部内容。基于该业务目标架构，SOA治理和管控又包括了如下关键内容：服务全生命周期管理中心SOA治理和管控一定要能够对服务全生命周期进行很好的管理，广义点的需要从企业业务目标和流程目标入手，到流程分析和需求分析，到服务识别和发现，到服务定义和设计，服务开发测试，服务上线的全过程有效的管理。对于服务识别和定义阶段，需要对业务域，服务目录，服务进行相应的元数据定义，以形成服务目录库。而服务目录库是后续服务使用和检索，服务设计开发测试的基本依据。能力提供中心SOA提供的服务本身就是一种能力，提能力提供中心的意义就在于要将服务转化为一种能力进行提供。达到业务组件化，组件能力化的目标。只要这样才能够更好的推进服务的重用，服务的编排和整合。对于能力提供中心包括了两个方面的内容，一个是服务前生命周期的管理可以实现服务的入库，服务入库后即转变为服务的能力提供。那么对于需求方可以对服务资产库进行检索，查看自己需要使用的能力，然X行服务申请，服务开通和使用。运维监控中心运维监控中心可以参考ITIL的标准进行构建，包括了事件管理，问题管理，变更管理，性能分析和监控，SLA管理，配置管理库等基本内容。运维监控中心是保证SOA平台能够高可用运行的基础。通过运维监控中心一方面是解决服务使用过程中遇到的问题，一方面是通过预警规则和策略的设置，能够及时的预警SOA平台存在的潜在问题，保证平台的高可用性。
其他网友回答
1、首先看下微服务是什么
微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。
2、再让我们看下api网关
服务的粒度，服务的划分，服务的功能都随时间或者需求会有不同程度的变化，服务之间的通信通过api来实现。
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。(本段取自百度，如有侵权请联系删除)
3、api网关治理
api治理实质上可以理解为api的用途自己实现
a、路由，api网关是服务的入口，通过路径的方式指向不同的服务
b、版本控制，通过版本号来控X务的不同时期的内容
c、协议统一处理，不同服务间的协议可能不同，需要统一的处理方式进行转换
d、权限控制，服务之间的交互，用户的登录等通过如jwt等方式进展限制与验证
e、限流，控X务的承载，保证主体业务的实时性与存活等
f、熔断，高峰期保证主体业务存活，阻断重要性低的服务
g、降级，优先级处理
4、灵活运用才是关键
根据不同的业务场景。技术背景选择符合自己的治理方式。
其他网友回答
老妖在带着团队弄微服务。对于API没想那么复杂。一是我们前后端开发时都由一个人负责，没分开。二是老妖定好了开发规范，直接使用Swagger生成API文档就可以了。
当然，如果你是前后端分离由不同人员开发的，那么API的定义文档是必须要有的了。不然，前后端人员经常打架是一定的了。
