低调的牛肉
都不要说微服务架构，就是单体应用架构中，API服务也是需要治理的。
首先是API接口文档的问题，这一点经常会被大家忽视，相信很多公司还在写接口文档，项目开始的时候还好，但是随着项目的发展，如果接口有改动，但是文档更新的不是那么及时甚至是不更新，那么这会加重团队之间沟通的成本。
虽然我们可以通过管理流程强制大家写文档，但是再怎么说，代码和文档是要修改两次的，难免会有疏漏。所以可以考虑使用一些框架或插件，自动地根据代码生成文档，这样开发人员只修改代码就好了，文档始终会和代码保持一致（当然开发人员还是要修改代码和Annotation，但是它们毕竟是在一起的）。
第二就是API接口测试的问题了，新开发一个接口很简单，难的是修改一个接口功能的时候，如何保证之前功能的正确性和稳定性；而对于接口调用方来说，同样需要确保自身依赖接口的正确性，因为用户是不会区别是你们系统的问题还是你们依赖系统的问题。我们是依靠单元测试覆盖率的统计和每天定时跑所有系统单元测试用例的方式，来提高各个系统的可用性（虽然这只是一种管理手段，单元测试用例覆盖率也很容易造假，但正是“防君子不防小人”）。
监控和缺陷追踪，如果是在分布式架构下，就是调用链路的管理；以往的系统，更多的是A系统调用B系统，而现在可能面对这A->B->C->D，而在这种情况下，如果没有链路跟踪的方案，那么查找和定位问题就会非常困难；这时候可以使用Sleuth来做服务之间调用提供链路追踪；使用Sleuth的时候，也可以和zipkin做集成，将搜集到的信息发送到zipkin，利用zipkin进行数据的存储和展示。
个人经验，新项目怎么都好说，老项目的改造是老大难，这种时候，可以考虑引入日志平台吧，对各个系统的API日志进行主动抓取，然后在日志平台里面加工展示。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
会点代码的大叔
1、首先看下微服务是什么
微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。
2、再让我们看下api网关
服务的粒度，服务的划分，服务的功能都随时间或者需求会有不同程度的变化，服务之间的通信通过api来实现。
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。(本段取自百度，如有侵权请联系删除)
3、api网关治理
api治理实质上可以理解为api的用途自己实现
a、路由，api网关是服务的入口，通过路径的方式指向不同的服务
b、版本控制，通过版本号来控制服务的不同时期的内容
c、协议统一处理，不同服务间的协议可能不同，需要统一的处理方式进行转换
d、权限控制，服务之间的交互，用户的登录等通过如jwt等方式进展限制与验证
e、限流，控制服务的承载，保证主体业务的实时性与存活等
f、熔断，高峰期保证主体业务存活，阻断重要性低的服务
g、降级，优先级处理
4、灵活运用才是关键
根据不同的业务场景。技术背景选择符合自己的治理方式。
