doc: add API7 Portal Architecture #34
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
|
||
| ### 组件说明 | ||
|
|
||
| 如上图所示，是c整体系统架构图，从上到下可以分为 UI 展示层、API7 portal 网关层、API7 portal dashboard 层、API7 portal 数据面层： |
...ocs/version-1.0.0/background-information/how-api7-portal-works/api7-portal-architecture-1.md
Outdated
Show resolved
Hide resolved
...ocs/version-1.0.0/background-information/how-api7-portal-works/api7-portal-architecture-1.md
Outdated
Show resolved
Hide resolved
...ocs/version-1.0.0/background-information/how-api7-portal-works/api7-portal-architecture-1.md
Outdated
Show resolved
Hide resolved
| ## 架构图 | ||
|
|
||
|  |
| ### 组件说明 | ||
|
|
||
| 如上图所示，是整体系统架构图，从上到下可以分为 UI 展示层、API7 Portal 网关层、API7 Portal Dashboard 层、API7 Portal 数据面层： | ||
| 1. Provider 通过 apisix 和 apisix-ingress-controller 进入 Provider Portal Dashboard； |
There was a problem hiding this comment.
这个文档是对外的吗？如果是对外部的架构介绍要这么多细节吗？我没看过那个SaaS产品会把自己用的所有组件都列举出来的。
There was a problem hiding this comment.
+1， 怎么把 filebeat， logstash 之类的全告诉给用户了。
There was a problem hiding this comment.
我觉得关键体现出来我们的数据面（表明我们用的是API7 Enterprise Edition），Provider Portal和developer portal，和用户的网关之间对接，就好了。中间的详细组件都不用暴露，统一告诉用户是我们的数据面就行。optional component和外部mail service什么的都不用提。
| 3. 整个 API7 Portal Dashboard 包含的组件有：provider-portal-ui、provider-portal、developer-portal、developer-portal-ui、PostgreSQL、etcd、keycloak、ES、Logstash 、Filebeat、API7-Gateway； | ||
| 4. API7 Portal Dashboard 与 数据面网关 API7-Gateway 通过 etcd 进行连接； | ||
| 5. Filebeat 组件采集 API7-Gateway 的日志发送给 logstash，然后由 logstash 写入 ES； | ||
| 6. 如最后一层显示，Developer 的 user，在访问 Provider 提供的上游服务时，首先会经历 API7-Gateway 这个前置网关，该中间层可以实现访问控制、限流限速等功能。 |
There was a problem hiding this comment.
该中间层可以实现访问控制、限流限速等功能
重点应该是货币化，就是 API 计费？我们现在也没有限流限速功能。
There was a problem hiding this comment.
这个是 sijing 的大纲里面要这么介绍的
| ### 组件说明 | ||
|
|
||
| 如上图所示，是整体系统架构图，从上到下可以分为 UI 展示层、API7 Portal 网关层、API7 Portal Dashboard 层、API7 Portal 数据面层： | ||
| 1. Provider 通过 apisix 和 apisix-ingress-controller 进入 Provider Portal Dashboard； |
There was a problem hiding this comment.
+1， 怎么把 filebeat， logstash 之类的全告诉给用户了。
|
|
||
| ### 系统可靠性说明 | ||
|
|
||
| 注意线上环境相比测试环境、预发环境需要注意以下几点： |
| ### 组件说明 | ||
|
|
||
| 如上图所示，是整体系统架构图，从上到下可以分为 UI 展示层、API7 Portal 网关层、API7 Portal Dashboard 层、API7 Portal 数据面层： | ||
| 1. Provider 通过 apisix 和 apisix-ingress-controller 进入 Provider Portal Dashboard； |
There was a problem hiding this comment.
我觉得关键体现出来我们的数据面（表明我们用的是API7 Enterprise Edition），Provider Portal和developer portal，和用户的网关之间对接，就好了。中间的详细组件都不用暴露，统一告诉用户是我们的数据面就行。optional component和外部mail service什么的都不用提。
|
|
||
| ### 组件说明 | ||
|
|
||
| 上图展示了 API7 portal 的整体系统架构图，从上到下可以分为 UI 展示层、API7 Portal 网关层、API7 Portal Dashboard 层、API7 Portal 数据面层： |
There was a problem hiding this comment.
API7 Portal 网关层不需要介绍。
UI 展示层是什么东西？ 第一次听说。
|
|
||
| 上图展示了 API7 portal 的整体系统架构图，从上到下可以分为 UI 展示层、API7 Portal 网关层、API7 Portal Dashboard 层、API7 Portal 数据面层： | ||
| 1. Provider 和 Developer 通过网关层进入 Provider Portal Dashboard； | ||
| 2. API7 Portal Dashboard 包含的组件主要有：provider-portal-ui、provider-portal、developer-portal、developer-portal-ui、API7-Gateway； |
There was a problem hiding this comment.
provider-portal-ui 和 provider-portal
developer-portal-ui 和 developer-portal 前后端分离部署也要介绍的这么清楚么？
| 1. Provider 和 Developer 通过网关层进入 Provider Portal Dashboard； | ||
| 2. API7 Portal Dashboard 包含的组件主要有：provider-portal-ui、provider-portal、developer-portal、developer-portal-ui、API7-Gateway； | ||
| 3. provider-portal、developer-portal 组件与数据面网关 API7-Gateway 通过 etcd 进行连接； | ||
| 4. 如最后一层显示，Developer 的 user，在访问 Provider 提供的上游服务时，首先会经历 API7-Gateway 这个前置网关，该中间层可以实现访问控制、限流限速等功能，然后才进入 provider 的网关（如果存在），再到 provider 的后端服务。 |
There was a problem hiding this comment.
我们现在还没有在 Gateway 上去支持配置限流限速功能吧？
| 1. 比如对于无状态的组件可通过多节点部署来保证节点的高可用；此外，在流量入口处有网关层，可以在网关层添加 LB、限流等机制来增加系统的稳定性； | ||
| 2. 对于有状态的组件，根据各个组件的自身的特性，可采用集群模式管理实现节点高可用，比如： | ||
| a. etcd 借助 Raft 协议，通过数据复制方案，可以提高服务可用性，避免单点故障，提升读吞吐量，降低访问延迟； | ||
| b. 关于 Filebeat 和 Logstash 聚合的高可用方案，单个 Logstash 的聚合处理能力有限，Logstash 将成为整个系统的瓶颈；另一方面，一旦 Logstash 崩溃退出，整个系统就将无法正常运行，同时 Filebeat 采集的数据得不到及时消费，造成数据丢失。为了解决当 Logstash 宕机时，数据丢失的问题，在 Filebeat 与 Logstash 中间加入 Kafka 做为消息中间件。 |
There was a problem hiding this comment.
这个是在给我们出解决方案了么？ （我们目前都没有用到 Kafka 作为消息中间件）
There was a problem hiding this comment.
我们的高可用都没有实现 文档里面需要体现下 我就写了个方案
| 2. 容错性，系统发生故障或违反指定接口的情况下，系统维持规定的性能级别的能力； | ||
| 3. 易恢复性，系统发生失效的情况下，重建规定的性能级别并恢复受直接影响的数据的能力，并且当出现问题时需要及时的反馈； | ||
| 4. 可扩展性，系统的部署模型需要考虑未来随着用户数量逐渐增多之后如何进行扩容； | ||
| 5. 可维护性，相关组件需要有能力进行运维，如果没有则采用 SaaS 服务来降低运维人力。 |
| 4. 可扩展性，系统的部署模型需要考虑未来随着用户数量逐渐增多之后如何进行扩容； | ||
| 5. 可维护性，相关组件需要有能力进行运维，如果没有则采用 SaaS 服务来降低运维人力。 | ||
|
|
||
| 对于部分难维护的组件 API7 Portal 选择了对应的 Saas 服务来保证系统的高可用能力。因此，API7 Portal 整体系统的高可用体现在各个需要自己部署的组件的高可用上，具体方案如下： |
There was a problem hiding this comment.
"API7 Portal 选择了对应的 Saas 服务来保证系统的高可用能力" 这个也是可以说的么 🤔️
| #### API 行为数据 | ||
|
|
||
| 1. API 行为数据指的是用户在 API7 Portal Dashboard 的一些操作在数据面 API7-Gateway 产生的数据。API7 Portal 提供了丰富的 API 运营分析能力，因此，需要追踪用户的一些 API 行为数据，用以统计展示。 | ||
| 2. 以 Developer 的 user 访问了 Developer 订阅的一个 API 为例，user 首先经过 API7 Portal 提供的中间层网关 API7-Gateway，再到 Provider 网关（如果存在），最后到 Provider 的一个上游服务。在这一过程中，会在数据面 API7-Gateway 采集 user 的 API 行为数据通过某种方式发送给 API7 Portal Dashboard，最后由 API7 Portal Dashboard 提供的 API 运行分析服务再进行聚合展示。 |
There was a problem hiding this comment.
通过某种方式发送给 API7 Portal Dashboard
通过某种方式？ 这个是故意隐藏的么。
No description provided.