环球数科

系统复杂且需求迭代频繁，如何维护微服务之间的接口调用关系？

API接口在设计的时候需要大量的需求文档，而且文档也需要不断维护。如何高效维护API文档就很重要了。以下是一些常见的API管理工具：Swagger：Swagger 是一套围绕OpeanAPI规范构建的开源工具，便于构建和使用REST API。
运用Skywalking等工具自动检测调用拓扑图，或者说依赖关系。

BUFFALO

如何在JVM层做隔离，防止一些问题比如多版本问题？参考本博------tomcat与自定义类加载器之 “使用自定义类加载器解决JAR包多版本冲突问题”
怎样做业务架构？

怎样做业务拆分¹？

一、按功能维度：
高内聚低耦合。

复用性：不同的业务里或服务里经常会出现重复的功能，比如每个服务都有鉴权、限流、安全及日志监控等功能，可以将这些通过的功能拆分出来形成独立的服务，也就是微服务里面的 API 网关。在如，对于滴滴业务，有快车和顺风车业务，其中都涉及到了订单支付的功能，那么就可以将订单支付独立出来，作为通用服务服务好上层业务。如下图：
在这里插入图片描述

避免环形依赖与双向依赖：尽量不要有服务之间的环形依赖或双向依赖，原因是存在这种情况说明我们的功能边界没有划分清楚或者有通用的功能没有下沉下来。

二、非功能维度:
扩展性：区分系统中变与不变的部分，不变的部分一般是成熟的、通用的服务功能，变的部分一般是改动比较多、满足业务迭代扩展性需要的功能，我们可以将不变的部分拆分出来，作为共用的服务，将变的部分独立出来满足个性化扩展需要。同时根据二八原则，系统中经常变动的部分大约只占 20%，而剩下的 80% 基本不变或极少变化，这样的拆分也解决了发布频率过多而影响成熟服务稳定性的问题。

高性能：将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其它服务。常见的拆分方式和具体的性能瓶颈有关，例如电商的抢购，性能压力最大的是入口的排队功能，可以将排队功能独立为一个服务。还有数据一致性是另一个基于性能维度拆分需要考虑的点，对于强一致的数据，属于强耦合，尽量放在同一个服务中（但是有时会因为各种原因需要进行拆分，那就需要有响应的机制进行保证），弱一致性通常可以拆分为不同的服务。

安全性：不同的服务可能对信息安全有不同的要求，因此把需要高度安全的服务拆分出来，进行区别部署，可以更有针对性地满足信息安全的要求。

异构性：对于对开发语言种类有要求的业务场景，可以用不同的语言将其功能独立出来实现一个独立服务。