You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
|
|
|
|
# 原理分析之文档归纳
|
|
|
|
|
|
|
|
|
|
作为开放平台，必须要提供API文档。
|
|
|
|
|
|
|
|
|
|
SOP采用微服务架构实现，因此文档应该由各个微服务各自实现。难点是如何归纳各个微服务端提供的文档信息，并统一展示。
|
|
|
|
|
|
|
|
|
|
SOP的解决思路如下：
|
|
|
|
|
|
|
|
|
|
- 各微服务使用swagger定义自己的接口信息
|
|
|
|
|
- sop-website项目在启动时向注册中心获取所有服务实例，分别调用各个服务提供的swagger文档信息，保存到本地
|
|
|
|
|
- sop-website前端页面负责展示swagger提供的文档信息
|
|
|
|
|
|
|
|
|
|
由于注册中心的存在，可以很方便的获取每个微服务提供的接口，因此可以获取到swagger提供的文档信息。
|
|
|
|
|
|
|
|
|
|
如此一来的好处是，各微服务不用关心文档改怎么展示，只需要写好swagger注解即可；文档信息展示统一交给另外一个工程来维护，各司其职。
|
|
|
|
|
|
|
|
|
|
SOP设计初衷亦是如此，微服务只管写业务代码，其它的都交给SOP来处理。
|
|
|
|
|
|
|
|
|
|
文档归纳原理图：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- sop-website服务启动时向各微服务获取接口信息，保存到本地
|
|
|
|
|
- 用户访问website页面，website提供对应的接口文档并展示
|
|
|
|
|
|
|
|
|
|
|
