精通API架构:设计、运维与演进
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

0.3.4 案例研究:演进步骤

为了开始考虑流量模式类型,在我们的案例研究架构中,采取一个小的演进步骤会很有帮助。在图0-4中,我们已经对参会者组件进行了重构,将其变成了一个独立的服务,而不是原有会议系统中的一个包或模块。现在,会议系统有两个数据流:参会者与原有会议系统之间的交互,以及原有会议系统与参会者系统之间的交互。

图0-4:C4会议系统上下文——演进步骤

南北向流量

在图0-4中,参会者与原有会议系统之间的交互被称为南北向流量,它代表了一个入口流量。参会者正在使用UI(用户界面),通过互联网向原有会议系统发送请求。这代表了我们网络中公开暴露的一个点,其将被UI访问[1]。这意味着任何处理南北向流量的组件在允许流量通过系统之前,必须对参会者身份进行具体检查,并包含适当的质询。第7章将详细介绍如何保护南北向API流量的安全性。

东西向流量

原有会议系统与参会者服务之间的新交互引入了系统内部的东西向流量。东西向流量可以被视为应用程序组内的服务与服务之间的通信方式。大部分东西向流量,尤其是如果源于基础设施内部,那么可以给予一定程度的信任。尽管我们可以信任流量的来源,但仍然有必要考虑保护东西向流量的安全性。