面向数据的架构( 四 )


我的建议是:如果您担心自己的架构存在水平扩展问题,那么就可以考虑以数据单体为中心来进行设计了 。
备注(1)服务到服务的 API 不一定是点对点的,但是组件到组件的直接通信通常意味着,为了达到某个给定的目的,需在两者之间传递参数 。
(2)一个架构的集成复杂度增长是否真能达到 N^2,实际上取决于架构的拓扑结构 。如果在我们使用的系统中集成是主要的瓶颈之一,则可能会遇到这个问题 。
例如,集成了各种流动资金提供者和场外交易(OTC)市场的交易系统,在理想情况下不应处于这样的场景中:每个管理市场订单的组件都需要了解每个提供流动资金的组件 。
(3)非常适合的 DOA 就是精心设计的 。
(4)假设服务调用对方是基于直接地址的(例如,IP 或正在运行的进程的某些内部地址模式),并且服务基于命令行参数能知道在何处访问特定的服务,那么就可能需要使用更适合的逻辑来包装这些服务了,对应的逻辑需要根据环境来构造正确的标志 。
(5) 例如,与其通过 IP 地址或特定于某个服务的内部 URI 来访问该特定服务,不如将每个服务构造在一个服务端路由的“路径”下 。例如,使用 ://env.namespace.company.com/Employees/* 而不是 ://process1.namespace.company.com/*

【面向数据的架构】


推荐阅读