读写分离的方法、设备、存储介质及程序产品与流程

1.本技术涉及计算机技术，尤其涉及一种读写分离的方法、设备、存储介质及程序产品。


背景技术：

2.在销售与运营计划、电子商务等业务系统中，存在大量的增加(create)、查询(retrieve)、修改(update)和删除(delete)操作，简称crud操作。对于比较简单的业务系统，直接查询单个数据库表，即可满足业务需求。在大规模的业务系统中，数据库中的数据模型很难和业务层需要的模型一致，于是引入了领域模型(domain model)，领域模型也称为业务对象模型，它专注于分析问题领域本身，发掘重要的业务对象并建立业务对象之间的关系，开发人员基于领域模型开发实现业务逻辑的程序代码。
3.但是，为满足大规模的业务系统的业务需求，业务系统的领域模型往往非常复杂，基于复杂领域模型开发的业务系统的可扩展性差。


技术实现要素：

4.本技术提供一种读写分离的方法、设备、存储介质及程序产品，用以提高业务系统的可扩展性。
5.第一方面，本技术提供一种读写分离的方法，包括：
6.响应于业务系统中的更新类的操作，运行所述业务系统中基于第一领域模型的第一代码模块，所述第一领域模型用于实现所述业务系统中更新类操作的业务逻辑；
7.响应于所述业务系统中的查询类的操作，运行所述业务系统中基于第二领域模型的第二代码模块，所述第二领域模型用于实现所述业务系统中查询类操作的业务逻辑；
8.其中，所述第一领域模型与所述第二领域模型不同。
9.第二方面，本技术提供一种读写分离的方法，包括：
10.响应于业务系统中的更新类的操作，执行所述操作对应的命令，新增所述命令对应的事件；
11.执行所述事件对应的业务逻辑；
12.其中，所述命令、所述事件、以及所述事件对应的业务逻辑是基于所述第一领域模型开发的，所述业务系统中用于实现查询类操作的业务逻辑的程序代码，是基于第二领域模型开发的，所述第一领域模型与第二领域模型不同。
13.第三方面，本技术提供一种读写分离的装置，包括：
14.更新单元，用于响应于业务系统中的更新类的操作，运行所述业务系统中基于第一领域模型的第一代码模块，所述第一领域模型用于实现所述业务系统中更新类操作的业务逻辑；
15.查询单元，用于响应于所述业务系统中的查询类的操作，运行所述业务系统中基于第二领域模型的第二代码模块，所述第二领域模型用于实现所述业务系统中查询类操作
的业务逻辑；
16.其中，所述第一领域模型与所述第二领域模型不同。
17.第四方面，本技术提供一种读写分离的装置，包括：
18.事件产生单元，用于响应于业务系统中的更新类的操作，执行所述操作对应的命令，新增所述命令对应的事件；
19.事件处理单元，用于执行所述事件对应的业务逻辑；
20.其中，所述命令、所述事件、以及所述事件对应的业务逻辑是基于所述第一领域模型开发的，所述业务系统中用于实现查询类操作的业务逻辑的程序代码，是基于第二领域模型开发的，所述第一领域模型与第二领域模型不同。
21.第五方面，本技术提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；
22.所述存储器存储计算机执行指令；
23.所述处理器执行所述存储器存储的计算机执行指令，以实现上述任一方面所述的方法。
24.第六方面，本技术提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现上述任一方面所述的方法。
25.第七方面，本技术提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述任一方面所述的方法。
26.本技术提供的读写分离的方法、设备、存储介质及程序产品，通过将更新类的业务逻辑使用的领域模型与查询类的业务逻辑使用领域模型的分离，第一领域模型和第二领域模型都简化了很多，在进行业务系统开发时，可以基于第一领域模型开发第一代码模块，基于第二领域模型开发第二代码模块，实现读写代码分离；对第一领域模型的修改不会影响查询类业务逻辑的实现，对第二领域模型的修改也不会影响更新类业务逻辑的实现，并提高业务系统开发的灵活性，开发完成的业务系统更便于维护和扩展，提高了业务系统的可维护性和可扩展性。
附图说明
27.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
28.图1为本技术提供的传统的基于领域模型的业务系统的总体框架的示例图；
29.图2为本技术一示例实施例提供的实现读写分离的系统框架示意图；
30.图3为本技术一示例实施例提供的读写分离的方法流程图；
31.图4为本技术另一示例实施例提供的读写分离的方法流程图；
32.图5为本技术一示例实施例提供的命令与事件的关系的示意图；
33.图6为本技术另一示例实施例提供的读写分离的方法流程图；
34.图7为本技术一示例实施例提供的事件的状态切换流程的示例图；
35.图8为本技术一示例实施例提供的基于sdk接入框架实现事件开发的系统框架示例图；
36.图9为本技术一示例实施例提供的读写分离的方法的一种示例框架图；
37.图10为本技术一示例实施例提供的事件回放处理的示意图；
38.图11为本技术一示例实施例提供的读写分离方法的业务系统的一示例框架图；
39.图12为本技术一示例实施例提供的读写分离的装置的结构示意图；
40.图13为本技术另一示例实施例提供的读写分离的装置的结构示意图；
41.图14为本技术另一示例实施例提供的读写分离的装置的结构示意图；
42.图15为本技术一示例实施例提供的电子设备的结构示意图。
43.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。
具体实施方式
44.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
45.首先对本技术所涉及的名词进行解释：
46.领域模型：又称概念模型、领域对象模型、分析对象模型，是对领域内的概念类或现实世界中对象的可视化表示。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
47.事件：是可以被控件识别的操作，如按下确定按钮，选择某个单选按钮或者复选框。每一种控件有自己可以识别的事件，如窗体的加载、单击、双击等事件，编辑框(文本框)的文本改变事件，等等。本实施例中，预先配置多个事件，以及事件的事件处理程序，事件的事件处理程序用于实现事件的业务逻辑。
48.销售与运营计划(s&op)：根据上游货品的销量计划，良品库存，以及预约采购量等，通过计算来预测未来的n天的货品维度的各项数据指标，运营可以参考这些指标决定当前产能是否支持活动，如果产能不足，及时调配或者更改计划。
49.此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。
50.本技术中，更新类的操作是指业务系统中需要新增、修改或删除数据的操作，更新类的操作的业务逻辑在执行时，会产生对数据库的写请求。更新类的业务逻辑是指更新类操作的业务逻辑。查询类的操作是指业务系统中只需查询数据，而无需新增、修改或删除数据的操作。查询类的操作的业务逻辑在执行时，会产生对数据库的读请求。查询类的业务逻辑是指查询类操作的业务逻辑。
51.对于早期的业务系统，业务功能较简单，数据访问层(repository)直接查询单个数据库表，即可满足业务需求。
52.但是，在销售与运营计划、电子商务等领域的大规模的业务系统中，业务系统的业务功能复杂，数据库中的数据模型很难和业务层需要的模型一致，于是引入了领域模型
(domain model)。为满足大规模的业务系统的业务需求，业务系统的领域模型往往非常复杂，基于复杂领域模型开发的业务系统的可扩展性差。
53.示例性地，传统的基于领域模型的业务系统的领域模型是基于业务系统的总体业务需求进行设计的，需要同时满足更新类和查询类的业务需求。传统的基于领域模型的业务系统的总体框架如图1所示，业务系统中的更新类操作和查询类操作对应于同一领域模型，基于同一领域模型实现对业务数据的更新和查询。
54.基于领域模型开发的业务系统，数据访问层需要对数据模型和领域模型进行来回转换，但领域模型往往又和具体的领域中的数据模型不同，需要引入视图模型(view model)，视图模型可以组合不同的领域模型，包含组合的所有领域模型的属性。在需要对数据库进行大量连接(join)时，数据访问层中的查询方法需要基于视图模型组装数据传输对象(data transfer object，简称dto)，并进行数据预加载，以提高系统性能，预加载的数据包含了大量不需要的领域模型的属性，占用大量内存，且需要进行数据维护，增加性能消耗。
55.本技术提供的读写分离的方法，旨在解决现有技术的如上技术问题，可以应用于销售与运营计划、电子商务等业务系统中，尤其适用于业务逻辑复杂的大规模业务系统。
56.下面以具体地实施例对本技术的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本技术的实施例进行描述。
57.图2为本技术一示例实施例提供的实现读写分离的系统框架示意图。本实施中，如图2所示，基于领域模型的业务系统的框架包括第一领域模型和第二领域模型，第一领域模型是针对更新类的业务需求设置的用于实现更新类业务逻辑的领域模型，第二领域模型时针对查询类的业务需求设置的用于实现查询类业务逻辑的领域模型，实现更新类的业务逻辑使用的领域模型与查询类的业务逻辑使用领域模型的分离。
58.相较于传统业务系统中的领域模型，第一领域模型和第二领域模型都简化了很多，基于第一领域模型开发用于实现更新类业务逻辑，基于第二领域模型开发用于实现查询类业务逻辑，实现读写代码分离，对第一领域模型的修改不会影响查询类业务逻辑的开发，对第二领域模型的修改也不会影响更新类业务逻辑的开发，能够防止出现crud模式中，对查询类业务逻辑或者更新类业务逻辑中的某一方进行改动，导致另一方出现问题的情况，提高业务系统开发及版本迭代的灵活性，并且开发完成的业务系统更便于扩展。
59.基于图2所示的系统框架，通过将更新类的业务逻辑使用的领域模型与查询类的业务逻辑使用领域模型的分离，在进行业务系统开发时，可以基于第一领域模型开发第一代码模块，基于第二领域模型开发第二代码模块，第一代码模型用于实现业务系统中更新类操作的业务逻辑，第二代码模型用于实现业务系统中查询类操作的业务逻辑。
60.图3为本技术一示例实施例提供的读写分离的方法流程图。如图3所示，本技术提供的读写分离的方法具体步骤如下：
61.步骤s31、响应于业务系统中的更新类的操作，运行业务系统中基于第一领域模型的第一代码模块，第一领域模型用于实现业务系统中更新类操作的业务逻辑。
62.可选地，该步骤s31可以采用基于现有的领域模型实现更新类操作的业务逻辑的方法实现。
63.可选地，该步骤s31还可以采用本技术中图4对应实施例及后续方法实施例中的任一实施例提供的方法实现，详见图4对应实施例及后续方法实施例的内容。
64.步骤s32、响应于业务系统中的查询类的操作，运行业务系统中基于第二领域模型的第二代码模块，第二领域模型用于实现业务系统中查询类操作的业务逻辑；其中，第一领域模型与第二领域模型不同。
65.该步骤s32可以采用基于现有的领域模型实现查询类操作的业务逻辑的方法实现。
66.本技术实施例中，通过将更新类的业务逻辑使用的领域模型与查询类的业务逻辑使用领域模型的分离，第一领域模型和第二领域模型都简化了很多，在进行业务系统开发时，可以基于第一领域模型开发第一代码模块，基于第二领域模型开发第二代码模块，实现读写代码分离；对第一领域模型的修改不会影响查询类业务逻辑的实现，对第二领域模型的修改也不会影响更新类业务逻辑的实现，并提高业务系统开发的灵活性，开发完成的业务系统更便于维护和扩展，提高了业务系统的可维护性和可扩展性。
67.一种可选地实施方式中，基于图2所示的系统框架，可以实现读写数据库的分离，也即配置两个数据库，并实现两个数据库的数据同步。用第一数据库和第二数据库分别指代这两个数据库，第二数据库与第一数据库中的业务数据保持同步。
68.第一数据库为写数据库，在需要更新业务数据时，对第一数据库中业务数据进行更新。在上述步骤s31中，响应于业务系统中的更新类的操作，运行业务系统中基于第一领域模型的第一代码模块时，更新第一数据库中的业务数据。
69.第二数据库为读数据库，在需要读取业务数据时，从第二数据库中读取业务数据。在上述步骤s32中，响应于业务系统中的查询类的操作，运行业务系统中基于第二领域模型的第二代码模块时，从第二数据库中读取业务数据。
70.可选地，第一数据库和第二数据库可以采用不同类型的数据库实现；或者，第一数据库和第二数据库可以采用同类型的数据库实现。第一数据库和第二数据库的类型可以进行配置和自定义，此处不做具体限定。
71.例如，第一数据库可以为非关系型数据库，第二数据库可以为关系型数据库；或者，第一数据库和第二数据库均可以为关系型数据库。
72.可选地，实现两个数据库的数据同步，可以采用同步方式或者异步方式实现数据同步，具体可以根据业务系统的需要进行配置和调整，此处不做具体限定。
73.示例性地，根据业务系统的业务需求，若需要保证用于读数据的第二数据库与用于写数据的第一数据库的强一致性，则采用同步方式实现第一数据库和第二数据库的同步。例如，当第一数据库中的业务数据发生变化时，实时地将第一数据库中发生变化的业务数据同步至第二数据库中。
74.示例性地，根据业务系统的业务需求，若能接受用于读数据的第二数据库与用于写数据的第一数据库的最终一致性，则采用异步方式实现第一数据库和第二数据库的同步。例如，每间隔指定时长，将第一数据库中的数据同步至第二数据库中，其中指定时长可以根据业务系统的实际需求进行设置和调整。
75.在实现读写代码分离的同时，实现读写数据库的分离，更新数据和查询数据基于不同的数据库实现，能够提高向数据库写入数据和从数据库读取数据的效率，能够在保证
数据安全性的同时，提高业务系统的性能。
76.另一种可选地实施方式中，基于图2所示的系统框架，基于第一领域模型的第一代码模型和基于第二领域模型的第二代码模块共享数据库。通过实现读写代码分离，使得业务系统的更容易维护和扩展，同时读写同一数据库，无需考虑读写的数据一致性问题。
77.可选地，若基于第一领域模型的第一代码模型和基于第二领域模型的第二代码模块共享数据库，在该数据库中，第一领域模型对应的数据库表与第二领域模型对应数据库表可以不相同，并保持不同数据库表中相同业务数据的一致性。
78.图4为本技术另一示例实施例提供的读写分离的方法流程图。基于图2所示的系统框架，本实施例中，在实现业务系统中更新类的操作的业务逻辑的第一代码模块中，将对数据库的更新类的操作封装为命令，将命令对应的业务逻辑封装为事件，事件被触发执行时实现对应的业务逻辑。其中，事件对应的业务逻辑也就事件对应的命令所对应的业务逻辑。
79.如图4所示，本实施例提供的读写分离的方法的具体步骤如下：
80.步骤s41、响应于业务系统中的更新类的操作，执行操作对应的命令，新增命令对应的事件。
81.其中，操作对应的命令是指将业务系统中更新类的操作封装成的命令。事件是根据命令对应的业务逻辑开发的，事件执行时用于实现对应命令的业务逻辑，事件的业务逻辑也即是事件对应命令的业务逻辑。
82.本实施例中，在业务系统开发阶段，根据业务系统中更新类的操作，封装生成多个命令，每一命令对应一类更新操作，并开发每一命令对应的事件及事件的事件处理程序，事件的数据处理程序用于实现事件对应的业务逻辑。基于封装好的命令，实现应用层的更新类操作的开发。
83.示例性地，在业务系统中所需的各类事件及事件处理程序开发完成之后，可以将各类事件的注册信息存储到缓存中，实现事件的注册。完成事件注册的事件可以在对应命令执行时被触发，执行事件的事件处理程序时实现事件对应的业务逻辑。
84.在开发应用层的更新类操作时，每一更新类操作可以使用一个命令实现，或者每一更新类操作可以组合多个命令实现，便于与其他的服务和系统的对接合作。
85.在业务系统使用过程中，响应于业务系统中的更新类的操作，执行操作对应的一个或者多个命令，每一命令执行时产生命令对应事件，在事件被执行时，实现事件对应的业务逻辑。
86.本实施例中，一个命令对应一个或者多个事件，命令被执行时产生对应的事件。命令与事件的关系至少包括如下几种：
87.(1)一个命令可以产生一个事件；
88.(2)一个命令可以产生多个事件，且多个事件之间没有依赖关系，多个事件执行的先后顺序不影响结果；
89.(3)一个命令可以产生多个事件，且多个事件之间具有依赖关系，多个事件需要按照指定顺序执行。
90.下面结合图5，对命令与所产生的事件的关系进行示例性地说明。如图5所示，用正方形代表命令，用圆圈代表命令所产生的事件，如图5最左侧矩形框内所示，一个命令可以产生一个事件；如图5中间位置的矩形框内所示，一个命令可以产生两个相互没有依赖关系
的事件，两个事件执行的先后顺序不影响结果；如图5最右侧矩形框内所示，一个命令可以产生两个具有依赖关系的事件，两个事件需要按照指定顺序执行。
91.步骤s42、执行事件对应的业务逻辑；其中，命令、事件、以及事件对应的业务逻辑是基于第一领域模型开发的，业务系统中用于实现查询类操作的业务逻辑的程序代码，是基于第二领域模型开发的，第一领域模型与第二领域模型不同。
92.其中，第二领域模型可以根据数据的使用方式进行构建，可以面向页面，也可以面向后端系统交互，无需受限于第一领域模型的结构，这样不但能够简化查询逻辑，还能提升系统的性能。
93.本技术实施例中，通过将业务系统中更新类的操作封装为命令，将命令对应的业务逻辑封装为事件，事件被触发执行时实现对应的业务逻辑，通过命令和事件解耦，实现业务系统上层的更新类操作发布事件，与事件执行实现操作对应的业务逻辑的解耦，一些对命令对应事件相关的处理逻辑的开发，仅仅需要考虑事件的发布，无需考虑事件的业务逻辑的具体实现和执行，提高了业务系统开发的灵活性和业务系统的可扩展性。
94.图6为本技术另一示例实施例提供的读写分离的方法流程图。在图4对应实施例的基础上，本技术的另一示例实施例中，新增命令对应的事件之后，存储事件的事件数据。在执行事件对应的业务逻辑时，通过事件处理器读取事件的事件数据，根据事件数据获取事件的事件处理程序，并执行事件的事件处理程序，事件处理程序用于实现事件对应的业务逻辑，实现事件发布与事件执行的解耦。
95.如图6所示，本实施例提供的读写分离的方法的具体步骤如下：
96.步骤s61、响应于业务系统中的更新类的操作，执行操作对应的命令，新增命令对应的事件。
97.其中，操作对应的命令是指将业务系统中更新类的操作封装成的命令。事件是根据命令对应的业务逻辑开发的，事件执行时用于实现对应命令的业务逻辑，事件的业务逻辑也即是事件对应命令的业务逻辑。
98.本实施例中，在业务系统开发阶段，根据业务系统中更新类的操作，封装生成多个命令，每一命令对应一类更新操作，并开发每一命令对应的事件及事件的事件处理程序，事件的数据处理程序用于实现事件对应的业务逻辑。基于封装好的命令，实现应用层的更新类操作的开发。
99.示例性地，在业务系统中所需的各类事件及事件处理程序开发完成之后，可以将各类事件的注册信息存储到缓存中，实现事件的注册。完成事件注册的事件可以在对应命令执行时新增命令对应的事件，存储该事件的事件数据。事件处理器根据事件数据，执行事件的事件处理程序，从而实现事件对应的业务逻辑。
100.在开发应用层的更新类操作时，每一更新类操作可以使用一个命令实现，或者每一更新类操作可以组合多个命令实现，便于与其他的服务和系统的对接合作。
101.在业务系统使用过程中，响应于业务系统中的更新类的操作，执行操作对应的一个或者多个命令，每一命令执行时产生命令对应事件，在事件被执行时，实现事件对应的业务逻辑。
102.本实施例中，一个命令对应一个或者多个事件，命令被执行时产生对应的事件。命令与事件的关系至少包括如下几种：
103.(1)一个命令可以产生一个事件；
104.(2)一个命令可以产生多个事件，且多个事件之间没有依赖关系，多个事件执行的先后顺序不影响结果；
105.(3)一个命令可以产生多个事件，且多个事件之间具有依赖关系，多个事件需要按照指定顺序执行。
106.下面结合图5，对命令与所产生的事件的关系进行示例性地说明。如图5所示，用正方形代表命令，用圆圈代表命令所产生的事件，如图5最左侧矩形框内所示，一个命令可以产生一个事件；如图5中间位置的矩形框内所示，一个命令可以产生两个相互没有依赖关系的事件，两个事件执行的先后顺序不影响结果；如图5最右侧矩形框内所示，一个命令可以产生两个具有依赖关系的事件，两个事件需要按照指定顺序执行。
107.步骤s62、以增量存储的方式，存储事件的事件数据。
108.该步骤中，在执行操作对应的命令，新增命令对应的事件之后，可以以只增的方式存储事件的事件数据，从而按照事件产生的先后顺序保存所以的事件数据。
109.其中，事件的事件数据可以包括：事件标识、事件类型、事件上下文、事件产生时间。另外，若支持事件异常重试机制，事件的事件数据还可以包括事件的重试次数和重试事件。事件数据具体包括事件的那些信息，可以根据业务系统的需要进行配置，此处不做具体限定。
110.示例性地，事件的事件数据可以存储在数据表中，事件数据所包含的信息如下表1所示：
111.表1
112.事件id事件类型异常重试次数重试时间间隔上下文信息1品协同35{
…
}2商协同35{
…
}3仓协同35{
…
}4全国聚合35{
…
}
……………
113.如图表1所示，事件id用于区分已产生的不同事件，基于事件id和事件类型可以唯一确定一个事件。
114.需要说明的是，表1中仅以事件数据包括事件id、事件类型、异常重试次数，重试时间间隔、上下文信息为例，进行示例性地说明，事件数据还可以包括事件产生的时间，事件异常重试的开始事件等等，此处不做具体限定。
115.在传统的业务系统中，当短时间内对数据库的更新操作频繁时，会协同多次操作的处理结果，将多次操作后的最终结果更新到数据库中，数据库不会记录每一操作的处理过程。
116.例如，在短时间内将数据库中的某一数据a进行如下操作：增加100，减少50，增加200，三次操作的最终结果是将a增加了250。如果三次操作间隔时间较短，在进行协同处理时，会根据三次操作的最终结果将数据库中的数据a增加250，而不会分别针对每一操作进行三次更新处理，数据库的更新日志只会记录一次更新的信息。
117.本实施例中，针对每一更新类的操作，执行操作对应的命令，新增命令对应的事
件，并存储事件的事件数据，会针对每一更新类的操作存储对应的事件数据。
118.例如，在短时间内将数据库中的某一数据a进行如下操作：增加100，减少50，增加200，三次操作的最终结果是将a增加了250。即使是三次操作间隔时间较短，在进行协同处理时，也会分别针对每一次操作，记录对应的事件数据。
119.可选地，基于存储的事件数据，在任何时候都能查到历史发生的事件的数据，为对业务系统的审查提供数据基础；也可以分析业务系统的性能和查看操作信息和分析行为趋势；还可以实现事件的回放功能，以进行数据恢复等。
120.可选地，存储的事件数据可以是事件的快照，基于事件的快照可以快速地进行事件回放。
121.可选地，事件数据可以存储在数据库中，具体可以存储在业务数据所在的数据库，或者将事件数据与业务数据隔离存储。另外，用于存储事件数据的数据库的类型可以配置，可以是自定义的数据库，此处不做具体限定。
122.本实施例中所存储的事件数据，包含对业务数据所有更新行为的信息，可以作为业务系统的操作日志，用于实现对业务系统进行回放。
123.步骤s63、通过事件处理器读取事件的事件数据，根据事件数据获取事件的事件处理程序，并执行事件的事件处理程序，事件处理程序用于实现事件对应的业务逻辑。
124.本实施例中，通过事件处理器读取事件的事件数据，根据事件数据获取事件的事件处理程序，并执行事件的事件处理程序，实现事件发布与事件执行的解耦。
125.可选地，通过事件处理器可以采用同步的方式执行事件。在执行操作对应的命令，新增命令对应的事件，存储事件的事件数据后，通过事件处理器根据事件数据，同步地进行事件处理，执行事件的事件处理程序。
126.可选地，通过事件处理器可以采用异步的方式执行事件。在执行操作对应的命令，新增命令对应的事件，存储事件的事件数据后。通过事件处理器，可以每间隔一个时间段，根据已存储的事件数据，对还未执行的事件进行集中处理。
127.可选地，事件和事件之间可以进行联动形成事件流，事件之间的联动可以通过对事件的配置实现。示例性地，事件a执行结束后，会触发事件b的执行，事件b的执行可以触发事件c的执行，事件a、b、c联动形成事件流。
128.在传统业务系统中，若在页面上对按钮重复多次点击，或者出现在某一时间段内操作频繁的情况，在短时间内的重复进行或频繁进行的多次操作，频繁更新数据库，可能会存在冲突或相互干扰。本实施例中，通过将执行操作对应命令来发布事件的过程，与事件执行的过程解耦，能够使得系统用户界面产生事件的过程可以不被干扰地进行，通过事件处理器执行事件对应的处理逻辑，能够避免冲突，可以极大地改善业务系统的性能和可扩展性，尤其对于用户展现层，大大提高业务系统的性能。
129.可选地，基于配置的事件异常重试机制，可以实现事件的异常重试。通过事件管理器，可以为开发的每一事件配置需要进行重试的异常的指定类型，以及重试次数和重试时间间隔。在执行事件对应业务逻辑的过程(也即执行事件的过程)中发生异常，若且发生的异常属于指定类型，则需要基于异常重试机制，执行步骤s64，重新执行事件对应的业务逻辑；若发生的异常不属于指定类型，则不需要重新执行事件对应的业务逻辑，事件执行失败。
130.步骤s64、若执行事件对应的业务逻辑时发生指定类型的异常，则根据事件对应的异常重试次数和重试时间间隔，重新执行事件对应的业务逻辑。
131.其中，指定类型，事件对应的异常重试次数和重试时间间隔，均可以通过前端页面进行配置和调整，此处不做具体限定。
132.该步骤中，若执行事件的事件处理程序时发生指定类型的异常，也即执行事件对应的业务逻辑时发生指定类型的异常，则根据事件异常处理机制进行处理，重新执行事件对应的业务逻辑。
133.若重新执行事件对应的业务逻辑时，仍然出现异常，且实际重试次数小于所配置的异常重试次数，则再次重新执行事件对应的业务逻辑，直至事件执行成功，或者实际重试次数大于或等于所配置的异常重试次数时，事件执行仍然出现异常，不再重试，事件执行失败。
134.可选地，基于配置的事件状态管理机制，可以实现事件的状态管理。事件数据可以包括事件状态。根据事件的处理阶段，更新事件数据中的事件状态。
135.示例性地，可以配置事件状态包括：初始化、处理中、成功、失败。当执行命令新增命令对应的事件时，事件的状态为初始化，存储事件的事件数据，该事件数据中记录了事件的状态为初始化状态。事件处理器读取事件的事件数据后，将事件的状态更新为处理中，事件处理器执行事件对应的处理逻辑。在事件对应的业务逻辑执行成功时，事件处理器将事件的状态更新为成功。在事件对应的业务逻辑执行失败时，事件处理器将事件的状态更新为失败。
136.进一步地，若配置了事件异常重试机制，事件的状态还可以包括：异常。在执行事件对应的业务逻辑时出现异常，根据事件异常重试机制，若无需重新执行事件对应的业务逻辑，则将事件的状态更新为失败；若需重新执行事件对应的业务逻辑，将事件的状态更新为异常；在事件对应的业务逻辑执行成功后，将事件的状态更新为成功；若结束事件异常重试之后，仍然未能成功执行事件对应的业务逻辑，则将事件的状态更新为失败。
137.可选地，基于事件状态管理机制，在上述步骤s63中，事件处理器在读取事件数据时，根据事件数据中的事件状态，可以确定事件是否被处理(也即执行)过。事件处理器可以读取事件状态为初始化的事件数据，从而获取到待处理的事件数据。
138.可选地，基于已存储的事件数据中的事件状态，还可以方便地查询执行失败的事件，从而及时地发现业务系统中的问题，有利于业务系统的维护。
139.例如，图7提供了事件的状态切换流程的示例图，如图7所示，事件的初始状态为“初始化”状态，当事件处理器读取事件的事件数据，或者开始执行事件对应处理逻辑时，事件的状态自“初始化”更新为“处理中”；当事件处理完成后，根据处理结果判断事件的下一个状态，如果事件的业务逻辑执行成功，事件的状态更新为“成功”。如果事件的业务逻辑执行过程中出现异常，且无需进行异常重试，则将事件的状态更新为“失败”。如果事件的业务逻辑执行过程中出现异常，且需进行异常重试，则将事件的状态更新为“异常”，在事件对应的业务逻辑执行成功后，将事件的状态更新为“成功”；在异常重试结束之后，事件对应的业务逻辑仍未执行成功，将事件的状态更新为“失败”。
140.本实施例中，通过事件处理器，基于sdk(software development kit，软件开发工具包)接入框架以及通用的运维配置页面，进行事件相关信息的配置和操作，能够降低事件
驱动操作的开发难度。
141.示例性地，图8提供了一种基于sdk接入框架实现事件开发的系统框架示例图，如图8所示，基于sdk接入框架实现事件注册、事件寻址路由、事件状态管理、事件异常重试等功能，并向业务系统提供事件的api，业务系统通过调用事件的api实现对事件的对应操作。
142.在业务系统开发阶段，根据业务系统中更新类的操作，封装生成多个命令，每一命令对应一类更新操作；并开发每一命令对应的事件及事件的业务逻辑。在事件开发完成后，进行事件注册，将事件的注册信息保存到缓存中。
143.事件注册：是指将事件的注册信息保存到缓存中。事件的注册信息可以包含事件类型、业务逻辑寻址信息等。
144.其中，事件类型也即事件对应命令的类型，不同事件的事件类型不同，基于事件的事件类型，可以唯一确定一种事件。
145.业务逻辑寻址信息包含事件对应的业务逻辑的寻址信息，根据业务逻辑寻址信息可以确定事件对应的业务逻辑的存储位置，从而能够读取到事件对应的业务逻辑。
146.另外，事件的注册信息还可以包括其他需要信息，具体可以根据业务系统的场景需要进行设置和调整，此处不做具体限定。
147.事件寻址路由：是指在需要执行事件时，根据事件的注册信息，确定事件对应业务逻辑的存储位置的过程。
148.事件状态管理：在业务系统开发阶段预先配置的事件的状态，在业务系统使用过程中，对于命令执行时产生的事件(也即事件的实例)，根据事件的处理阶段更新事件的状态。示例性地，事件的状态可以包括：初始化、处理中、执行成功、执行异常、执行失败等。事件包括哪些状态可以根据业务系统的需要进行配置和调整，此处不做具体限定。
149.事件异常重试：是指在执行事件的业务逻辑的过程中，若出现指定异常，可以根据配置的重试次数和重试时间间隔，重新执行事件的业务逻辑，直至事件执行成功；或者重试次数达到所配置的重试次数时还未执行成功，则事件执行失败。
150.本实施例中，对事件的操作包括以下至少一项：新增、执行、查询。事件的操作具有对应的api，事件的新增、执行、查询操作分别对应事件的新增api、执行api、查询api。
151.其中，事件的新增是指在事件对应的命令执行时新增事件的事件数据，通过调用事件的新增api来新增事件数据。事件的执行是指执行事件对应的业务逻辑，通过调用事件的执行api来执行事件对应的业务逻辑。事件的查询是指查询事件的相关信息，如事件的配置信息等。通过调用事件的查询api来查询事件的相关信息。
152.另外，为了支持多个接入方接入不同的业务系统，可以提供数据源隔离和与应用隔离，保证不同的接入方的行为和数据不会共享。示例性地，可以将不同接入方的业务系统的数据库和应用程序代码，部署到接入方对应的物理设备上，实现物理隔离。
153.示例性地，图9提供了读写分离的方法的一种示例框架，如图9所示，响应于业务系统中的更新类的操作，执行操作对应的命令，存储新增的命令对应事件的事件数据，事件数据中记录事件的状态。事件处理器读取事件(读取事件的业务逻辑)，执行事件对应的业务逻辑，以及更新事件的状态。事件的业务逻辑被执行时，将更新结果写入业务数据。响应于业务系统的查询请求，查询业务数据。
154.本实施例提供的读写分离的方法，通过将业务系统中更新类的操作封装为命令，
将命令对应的业务逻辑封装为事件，事件被触发执行时实现对应的业务逻辑，实现了业务系统从数据驱动转到事件驱动，能够在业务系统开发阶段实现命令和事件解耦，一些对命令对应事件相关的处理逻辑的开发，仅仅需要考虑事件的发布，无需考虑事件的业务逻辑的具体实现和执行，提高了业务系统开发的灵活性和业务系统的可扩展性。
155.本实施例提供的读写分离的方法，尤其适用于一些需要对查询性能和写入性能分开进行优化的系统，尤其是读/写比非常高、需要横向扩展的系统。业务系统中所有涉及到对数据库的更新类的操作都是通过执行操作对应的命令，触发命令对应事件来实现，执行命令与执行事件的过程可以是异步的，并且所有涉及到对业务数据的更新行为都包含在具体的事件中，通过存储所有事件的事件数据，可以实现事件的回放功能，实现业务系统的回放。
156.进一步地，通过实现更新类操作和查询类操作的代码分离，提高了业务系统的性能、可扩展性和安全性，并且能够在系统的演化(版本迭代)中保持高度的灵活性，对第一领域模型的修改不会影响查询类业务逻辑的实现，对第二领域模型的修改也不会影响更新类业务逻辑的实现；并且，通过存储所有事件的事件数据，能够基于事件数据对系统中的哪些行为或者操作导致了系统的状态变化进行溯源。
157.本实施例的一种可选地实施方式中，存储了所有事件的事件数据，除了提供事件数据点存储、查询功能以外，根据事件数据，可以重新执行至少一个事件数据对应的事件，实现事件回放功能。
158.示例性地，如图10所示，对于已产生的事件1，事件2，
……
，事件n，事件n 1，事件n 2，可以根据已存储的事件数据，从任一事件处开始进行事件回放处理。
159.可选地，事件数据包括事件产生时间。事件回放功能的一个示例为：
160.根据事件数据中的事件产生时间，获取在指定时间点之前产生的事件的事件数据；将业务系统的初始业务数据初始化数据库；根据在指定时间点之前产生的事件的事件数据，按照事件产生事件的顺序，依次执行在指定时间点之前产生的每一事件的业务逻辑，以将数据库中的业务数据恢复到指定时间点的业务数据。
161.通过事件的回放功能，可以将数据库中的业务数据恢复到任意的时间点。
162.示例性地，事件的回放可以通过将截止某一个指定时间点的所有事件数据取出来，放入事件的上下文，调用事件对应的业务逻辑，生成当时那个特定时间点的业务状态，以将业务数据恢复到指定时间点。
163.可选地，基于事件的回放功能，能够实现撤销操作的修正操作。例如，在完成对数据b的修改操作的第一时刻，执行了对上一操作的撤销操作，并记录了撤销操作对应事件的事件数据。通过根据撤销操作对应事件的事件数据，再次执行该事件，即可撤销上一次的撤销操作，恢复到第一时刻的业务数据。
164.通过只增方式存储所有事件的事件数据，事件数据包括事件的上下文信息，基于已存储的事件数据，实现事件回放功能，能够读取事件并放入上下文，重新调用执行事件对应的业务逻辑，将业务数据恢复到任一指定时间点，提高业务数据的安全性。
165.上述实施例中图3对应实施例可以与后续任一方法实施例结合，形成新的实施例，新的实施例也在本技术的记载范围内，例如图3对应实施例可以与图4对应实施例结合，形成读写代码分离的方案，针对更新类的操作采用封装命令和事件的方式实现的新的技术方
案。另外，图3对应实施例还可以与图6对应实施例相结合，得到新的技术方案，此处不再赘述。
166.图11为本技术提供的读写分离方法的业务系统的一示例框架图。如图11所示，以s&op场景的业务系统提供可视化的s&op用户界面，并提供以下两个不同的领域模型：更新模型和查询模型，其中，更新模型作为第一领域模型，用于实现更新类操作的业务逻辑；查询模型作为第二领域模型，用于实现查询类操作的业务逻辑。基于第一领域模型开发命令服务，提供各更新类操作对应的命令，命令执行时产生对应的异步事件，异步事件是指可以与事件产生异步执行的事件，支持事件的异步执行的功能，并能够实现导出、协同、重算等业务功能。通过事件处理器进行事件处理，执行事件对应的业务逻辑，在执行事件对应业务逻辑过程中，通过数据访问层更新数据库中的业务数据。基于第二领域模型开发查询服务，用于实现查询类操作的业务逻辑，通过数据访问层查询业数据库中的业务数据。另外，业务系统还支持存储事件快照的功能，事件快照可以存储在自定义的数据库中，基于事件快照可以实现事件回放功能。
167.图12为本技术一示例实施例提供的读写分离的装置的结构示意图。本技术实施例提供的读写分离的装置可以执行读写分离的方法实施例提供的处理流程。如图12所示，该读写分离的装置120包括：更新单元121和查询单元122。
168.具体地，更新单元121，用于响应于业务系统中的更新类的操作，运行业务系统中基于第一领域模型的第一代码模块，第一领域模型用于实现业务系统中更新类操作的业务逻辑。
169.查询单元122，用于响应于业务系统中的查询类的操作，运行业务系统中基于第二领域模型的第二代码模块，第二领域模型用于实现业务系统中查询类操作的业务逻辑。
170.其中，第一领域模型与第二领域模型不同。
171.可选地，第一代码模块运行时更新第一数据库中的业务数据；第二代码模块运行时从第二数据库读取业务数据，第二数据库与第一数据库为不同的数据库，第二数据库与第一数据库中的业务数据保持同步。
172.本技术实施例提供的装置可以具体用于执行上述图3对应实施例所提供的方法流程，具体功能此处不再赘述。
173.本技术实施例中，通过将更新类的业务逻辑使用的领域模型与查询类的业务逻辑使用领域模型的分离，第一领域模型和第二领域模型都简化了很多，在进行业务系统开发时，可以基于第一领域模型开发第一代码模块，基于第二领域模型开发第二代码模块，实现读写代码分离；对第一领域模型的修改不会影响查询类业务逻辑的实现，对第二领域模型的修改也不会影响更新类业务逻辑的实现，并提高业务系统开发的灵活性，开发完成的业务系统更便于维护和扩展，提高了业务系统的可维护性和可扩展性。
174.图13为本技术另一示例实施例提供的读写分离的装置的结构示意图。本技术实施例提供的读写分离的装置可以执行读写分离的方法实施例提供的处理流程。如图13所示，该读写分离的装置130包括：事件产生单元131和事件处理单元132。
175.具体地，事件产生单元131，用于响应于业务系统中的更新类的操作，执行操作对应的命令，新增命令对应的事件。
176.事件处理单元132，用于执行事件对应的业务逻辑。
177.其中，命令、事件、以及事件对应的业务逻辑是基于第一领域模型开发的，业务系统中用于实现查询类操作的业务逻辑的程序代码，是基于第二领域模型开发的，第一领域模型与第二领域模型不同。
178.本技术实施例提供的装置可以具体用于执行上述图4对应实施例所提供的方法流程，具体功能此处不再赘述。
179.本技术实施例中，通过将业务系统中更新类的操作封装为命令，将命令对应的业务逻辑封装为事件，事件被触发执行时实现对应的业务逻辑，通过命令和事件解耦，实现业务系统上层的更新类操作发布事件，与事件执行实现操作对应的业务逻辑的解耦，一些对命令对应事件相关的处理逻辑的开发，仅仅需要考虑事件的发布，无需考虑事件的业务逻辑的具体实现和执行，提高了业务系统开发的灵活性和业务系统的可扩展性。
180.图14为本技术另一示例实施例提供的读写分离的装置的结构示意图。在上述图13对应实施例的基础上，本实施例中，如图14所示，该读写分离的装置130还包括：
181.事件数据管理单元133，用于：以增量存储的方式，存储事件的事件数据。
182.事件处理单元132还用于：通过事件处理器读取事件的事件数据，根据事件数据获取事件的事件处理程序，并执行事件的事件处理程序，事件处理程序用于实现事件对应的业务逻辑。
183.可选地，事件的事件数据包括：事件对应的异常重试次数和重试时间间隔。
184.事件处理单元132还用于：
185.若执行事件对应的业务逻辑时发生指定类型的异常，则根据事件对应的异常重试次数和重试时间间隔，重新执行事件对应的业务逻辑。
186.可选地，如图14所示，该读写分离的装置130还包括：
187.事件回放处理单元134，用于：
188.根据已存储的事件数据，重新执行至少一个事件数据对应的事件的业务逻辑。
189.可选地，事件数据包括事件产生时间，事件回放处理单元134具体用于：
190.根据事件数据中的事件产生时间，获取在指定时间点之前产生的事件的事件数据；将业务系统的初始业务数据初始化数据库；根据在指定时间点之前产生的事件的事件数据，按照事件产生事件的顺序，依次执行在指定时间点之前产生的每一事件的业务逻辑，以将数据库中的业务数据恢复到指定时间点的业务数据。
191.本技术实施例提供的装置可以具体用于执行上述图6对应实施例及后续任意一方法实施例所提供的方法流程，具体功能此处不再赘述。
192.本技术实施例，通过将业务系统中更新类的操作封装为命令，将命令对应的业务逻辑封装为事件，事件被触发执行时实现对应的业务逻辑，实现了业务系统从数据驱动转到事件驱动，能够在业务系统开发阶段实现命令和事件解耦，一些对命令对应事件相关的处理逻辑的开发，仅仅需要考虑事件的发布，无需考虑事件的业务逻辑的具体实现和执行，提高了业务系统开发的灵活性和业务系统的可扩展性；进一步地，通过只增方式存储所有事件的事件数据，事件数据包括事件的上下文信息，基于已存储的事件数据，实现事件回放功能，能够读取事件并放入上下文，重新调用执行事件对应的业务逻辑，将业务数据恢复到任一指定时间点，提高业务数据的安全性。
193.图15为本技术一示例实施例提供的电子设备的结构示意图。如图15所示，该电子
设备150包括：处理器151，以及与处理器通信连接的存储器152。
194.其中，存储器152存储计算机执行指令；处理器151执行存储器152存储的计算机执行指令，以实现上述任一方法实施例提供的读写分离的方法，具体功能及所能实现的技术效果参见上述方法实施例，此处不再赘述。
195.本技术还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现上述任一方法实施例提供的读写分离的方法。
196.本技术还提供了一种计算机程序产品，包括计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一方法实施例提供的读写分离的方法。
197.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
198.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
199.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
200.上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本技术各个实施例方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
201.本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
202.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由下面的权利要求书指出。
203.应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求书来限制。