你知道什么是 EDA 么
**环保路上**
**同行你我**
**你问我答**
**问**
你知道什么是EDA吗？
**答**
** 写在前面 **
本文是基于客户需求背景在架构设计与实现层面的一次探索，由于项目仍在实践探索过程中，所以当下能提供的并不是完善的业务到技术侧的实现方案，而是仅在架构与方案上开拓一下思路。
文章只代表当下从业务侧个人的浅薄认知，欢迎集思广益，给我们输入建设性意见。
** 1\. 什么是EDA **
**Event-driven architecture (EDA)** is a design paradigm in which a software
component executes in response to receiving one or more event notifications.
EDA is more loosely coupled than the client/server paradigm because the
component that sends the notification doesn’t know the identity of the
receiving components at the time of compiling.
In 2018, gartner cited the event-driven model as one of the top technology
trends for 2018 . That report made some bold predictions
• By 2022, event notifications will form part of over 60% of new digital business solutions.
• By 2022, over 50% of business organizations will participate in event-driven digital business ecosystems.
• By 2022, 50% of organizations managing APIs will incorporate mediation of event notifications into their operations.
• By 2022, most leading providers of application platforms will include high-productivity tools for event-driven design.
• cited from gartner
**简单画个图做个示例：**
这里的事件如针对销售订单完成登记，销售管理领域在完成订单登记后，产生事件进行传递，而无需知道下游存在哪些领域需要消费，下游对于事件进行判断是否需要响应处理，在各自的领域内完成事件的流程闭环。
因此对于各自领域而言，只需要在领域内完成业务闭环即可，而无需对整条交易链路进行流程固化。这样的一个好处是通过领域的组合，领域内服务能力与流程的组合，可以灵活定义对业务的支撑，而无需牵一发而动全身。
**2\. 什么样的场景导致我们走向了这个架构**
**2.1 客户需求**
客户是一家背靠基建行业集团的集采贸易与物流公司，以往靠着城市化、大基建的时代背景与集团公司的项目资源与缺口，实现了很好的业绩增长与收入表现。从宏观角度来看，房地产与基建行业进入价值回归的周期，以及地方债务问题以及相关的基建项目的叫停，导致整个行业蛋糕已经被国家缩小。从微观角度来讲，随着上游供应商的产业整合与数字化转型的推进，DTC将进一步提高厂商的影响力以及形成对纯贸易时差、价差带来利润的挤压。
所以客户也面临着要么在存量市场中，在不断被压缩的利润空间中逐步失去竞争力，要么通过转型引入高附加值的增值服务来通过取得新的收入增长点。其中包括通过商品、物流、资金整合优化，输出供应链解决方案，降低综合交付成本是一种策略，通过输出专业的供应链托管服务，减少客户侧对专业性人员的依赖也是一种策略。但是两者都需要依赖平台化的能力工具来降低沟通成本，规模化以及放大单位人员投入所产生的效能。
这里也让我想起了之前AC大连BPO的在摩拜的业务模式，通过供应链业务外包，由BPO完成供应商寻源等事务性以及系统合规上的工作，由供应链核心团队基于BPO的决策素材整理，输出供应链决策后，执行监控、系统数据录入等都通过BPO来做执行，这样大大减少了供应链团队在事务性工作上的时间占用，因此也带来了人力成本上的优化。
我想如果基建项目中，通过这样一家服务商来管理履约交付，有能力对供应链的风险兜底，同时在资金上可以帮忙出具一定的方案的话，对比单物资的供应商其服务整合能力所带来的价值会在供应商选择环节中带来更多的综合竞争优势。
所以这里就引出了客户对这套解决方案的定位：
**1.平台化**
当解决方案的定位是通过数字化平台输出服务与解决方案时，这就决定了这套产品不同于面向企业内部管理的ERP，也不同于围绕在中心业务外围的CRM或者SRM，同时其业务模式也不同于上文中提到的AC大连的BPO模式。而是基于同一套数字化工具来输出配套管理服务。
理想化的场景下，这就要求介入这套平台的上下游在同一平台上进行业务的协作，此时对于入驻平台的公司可以低成本获取到平台提供的B端供应链管理的基础能力，能够在平台生态内低成本的实现业务的协作，同时通过其所链接的资源能力可以持续在生态中输入需求与分享价值。
**2.多租协同**
这里又出现了不同于现有传统的saas产品的场景，对于绝大多数当下的saas产品通过同一套产品满足不同企业某一领域下的管理需要，通过产品迭代持续提供新功能来持续给客户交付价值，其注重的是通过功能满足单一租户的能力需要，而不是在于减少公司间协作与信息互通的成本。
而对于当下客户的场景，是需要需求方、第三方、承运商、金融服务商、司机等在同一平台中进行协作，在当下中心化的技术架构条件下，优先实现去中心化的数据管理，以及多租之间的数据协同。为后续理想化的去中心化的技术架构与数据架构保留一定的可能性。
在实际业务中会存在以下的交易链路：
链路中依托需求方的签收，实现如下的商流：
a .需求方与第三方的物资（含运费）的结算
b .第三方与第四方的物资（含运费）的结算
c .第四方与厂商物资结算
d .第四方与承运方的运费结算
e .承运方与司机的费用结算
此时，如果系统构建站在单一环节来看，这是传统ERP以及企业内部管理系统所能解决的范畴，但是涉及到交易链路上信息的协同传递，目前确实没有接触到相关的产品厂商提供相应方案的，毕竟这个非常依赖背后的资源影响力。纯IT服务商或者产品提供商，即便做出来这个东西，在没有足够的资源接入时，确实也很难产生影响力。
同时，考虑到租户之间的数据屏蔽要求、安全性与数据的差异性，我们不得不引入分布式账本概念，即每个租户都具备交易的所有数据，因为当前在技术架构上还是中心化的，因此尚不用引入区块链来做交易存证。
**2.2 流程驱动为什么不能满足**
在项目的一开始，我们确实有考虑通过我司斑羚流程平台，通过流程编排系统节点来实现对流程环节中各领域服务能力的调用，但是我们很快遇到了问题：
**1\. 我们无法在开始就明确交易链路**
对于贸易业务而言，我们很难去穷举业务模式，以及业务链路环节，在现实业务中这是一个很灵活动态变化的过程，同样是一个客户的相同商品需求，这一时刻我没有库存或者库存履约的成本高于供应商履约，那我可能直接就找供应商履约了，供应商也会存在着在这个平台内协同，或者不在这个平台上协同，可能下一时刻另一个客户的一笔退货入库后，使得我某个子公司下有了这么一批货，我通过内部交易，由子公司委托第三方物流，发给客户，满足需求。
因此对于一个灵活的业务处理过程，如果我要通过流程驱动拉通如此多的环节，那么这个流程网络无论是对于IT还是对于业务，都是一个灾难，更不用提我们如何保证能够保证各环节中对多领域的服务调用是没有遗漏的，以及业务需求变更如何确保原有流程的调整可行的同时不会存在遗漏。
如果不能穷举，另一个方法是在流程节点中去实现动态流程环节的生成，这个很抱歉，确实是项目周期内研发资源能力有限以及对于公司标准产品做开发确实不是一个交付性质的项目所应该考虑的路径。
**2\. 穷举配置将失去业务的灵活性以及分布式的可能**
即便对于流程驱动，那总要有一个地方能够定义与发布流程，考虑到平台各领域与相关领域的微服务架构，以及密密麻麻的服务调用，把这个事情交个任一一个租户的管理员去配，将又是一个灾难，就像灵活跟好用不可兼得一样。
另外就是即便斑羚实现了跨租户的流程协同，但是前提也是有把定义的流程要么放到平台层，要么放到单一租户，那后续租户之间的协同依赖平台或者源头租户配合进行流程的定义。所以这还是一个中心化的服务能力，配合的租户无法自主进行流程的变动。
**3.过程的个性化，但是一致的结果**
那我们回归业务的本质，无论不同的企业对于流程中的管理规则与控制、审核审批流程怎样的千差万别，或者管理系统由不同的产品、架构与团队来运营，但是这些都是过程管理的手段，落实到最终的交易结果来讲，最终还是回到了事务型的业务本质，如商品的交接，服务的确认，对账单的签章等等，这些结果性的东西是可以忽略过程管理的差异性的，也是平台信息协同的基础。
**2.3 为什么考虑事件驱动**
** 1.多领域协同 **
由于对于当下贸易企业的背景以及后续规划构建的加工板块，该公司在“遥遥领先”整体的规划牵引下，需要在单一的技术架构上，分批逐步完成几十个管理领域的产品建设。结合微服务的架构要求，也就要求我们做好领域间的限界划分以及通过领域的协同来支撑业务流程开展。
当下项目，一方面结合DDD的指导以及过往项目的经验，我们划分了6个领域，构建了5个小团队。
此时对于上游领域而言，对于事务性的对接，为减少下游领域的逻辑侵入，最好的方式是上游通过事件的方式将动作所关联的原始单据信息与下游实现交互，那么下游的逻辑变更可以有效减少对上游的依赖，上游领域的负责人也无需对下游领域的处理细节投入更多的精力来了解。
通过这种方式，来实现领域之间的弱耦合，能够使领域业务与技术专注于自己领域的逻辑闭环与能力实现，而减少外部依赖所带来的变更与不确定。
** 2\. 多租协同 **
就像前文多租协同提到的，对于源头一个租户的事件，会产生对整个交易链路的信息更新。那么如果我们仍采用服务调用的方式来实现的时候，如果需要提供租户对租户的服务调用，那么意味着源头租户需要同时调用多个租户的相同或不同接口，并取得成功返回，这样不仅在用户体验上存在延迟，同时也会导致事务的失败可能，比如某个租户节点宕了等等。
而通过事件流，可以规避这种依赖，同时假设单一租户宕机，到其重启之后，仍可以顺序消费事件，直到需要该租户响应处理的事件被处理后，多租协同的流程则可以继续流转。
同时这里对于事件体的定义，我们尽量采用事件的原始属性，如商品已经发出，商品已经签收，忽略交易中的中心化属性，如所关联的合同，交易的双方定价等。关于价格等信息，由环节各租户在消费事件后，基于自身记录的数据重新赋值，这样以规避敏感信息的泄漏。
** 3.追溯交易链路 **
所谓追溯交易链路还是回到了前面多租协同的事情上，因为供应商的发货信息要同步到交易链上的各个环节，但目前中心化的基础架构尚不需要区块链的共识算法，所以站在这个角度上，如果我们把交易信息做成广播，要求所有租户都进行消费的话，假设平台一万个租户协同，那么有效消费数量至多千分之一，其他租户在消费与忽略不相关事件，但是在判断与处理上仍需要大量的系统开销，导致噪音盖过真实声音。就有点像现在你被拉到包括微信、企微、钉钉、飞书、welink各种群中，各种信息扑面而来，可能90%跟你没关系，但是仍在开销你的时间消费信息，判断跟你无关一样。🙄
这时我们就需要通过数据标注来实现对多租中数据流转的追溯，以确认一个事件的发生所影响的范围，这里又遇到一个新的问题，要如何来做，对于这种分布式的业务系统，目前来看可能交易量大的电商是应该是会有的，但是就我的资源渠道以及开放网络上的资源，确实难以获取到解决方案。
这里同时去了解了其他开源分布式系统协同的方案，典型的如mastodon其中Sidekiq挺有意思的，通过取得关注人、跟贴人，启动若干后台任务去建立分布式点对点的通信。但是落在我们这边好像也不是很合适，毕竟这里在交易链路上会存在劈叉，举个例子来说：
这里当厂商B无法在线协同时，由贸易商B代为发货时
• 贸易商B代厂商B发货，交易涉及链路上：客户、贸易商A、厂商B
• 贸易商B使用自有库存发货，交易涉及链路上：客户、贸易商A
因此我们所需要的数据追溯不仅要追溯到最源的客户需求还需要建立树的路径标记，以此来取得树路径的交易链路，对交易链路上发送事件。
** 3\. 相关阅读材料 **
AWS：https://aws.amazon.com/cn/what-is/eda/
Microsoft：https://learn.microsoft.com/en-
us/azure/architecture/guide/architecture-styles/event-driven
** 写在最后 **
EDA是一种架构模式，但是一个项目一个产品并非只有唯一的架构模式，实际落地中完全可以通过多模式相互结合的方式，考虑当下业务场景，业务需求中最适合的方式。
**作者：熊旭东**
**审核：何 楠**
**编辑：朱思聪**
