一、  概述

 好的方案能很好的符合客户的价值主张，能很好的满足客户的需求点，有些核心的方案是项目成功的关键和保障，好的方案不仅能提高开发效率，能缩短开发周期，节省开发成本，减少重复修改和返工的时间，并且后期维护也会简单方便，能增加客户对专业度的认可，对团队成员的信任，从而大大提高客户满意度，下面以实际案例来说明一下当我们面对一个大型方案，会对项目造成重要影响的时候，如何去设计，从哪些角度去思考，如何应对客户的需求，下面以具体的一个大型拆分项目为例来分享当初是如何去思考和设计，如何用创新思维去思考，如何去设计好这个方案的？ 

二、  项目背景

（1）   客户是我们最大的星空客户，从2017年使用星空企业版，2019年从6.0升级到7.1，由于数据量达到接近4.5T,47个组织，用户接近3500个，并发用户在1300左右，由于数据量、版本比较低，并发量大，造成高峰期性能受到一定影响

（2）   第三方系统有30多个，其中有接近20个第三方系统与星空有做集成

（3）   项目从2月份开始启动，本计划10月份上线，但客户要求必须5.1上线，否则还得多等几个月才能上线，这样造成开发和测试的时间不足2个月，时间太紧

三、  项目需求

（1）   需要先将一个账套拆分为2个账套，然后再继续拆分，计划拆分为4个账套，拆分需要做成灵活可配置，能满足多次账套拆分，

（2）   第三方系统能像拆分前一样能动态根据组织能进入不通账套处理业务，并支持多次拆分也不需要再做任何开发调整

（3）   角色和授权需要同步，只是用户对应的角色不同步

（4）   单据中的报价表过去是多组织公用的，拆分后需要同步

（5）   过去跨组织是可以查询库存的，拆分后必须在一个账套内能完成其他账套的库存查询

四、  项目设计思考

（1）   项目最大的特点就是动态性设计，因为必须满足动态寻址需求和多次拆分需求，作为系统整体架构设计负责人，则需要考虑能适应更多的场景。能做到动态扩展，并能通过一系列配置来完成。

（2）   第三方登录时一般为了安全性，尽量采取密钥文件的方式来进行登录验证，那密钥文件如何能也做到动态呢？也就是每次登录时根据配置信息，能对应到对应账套的密钥。

（3）   跨数据中心同步需调用WEB API接口，但如果涉及到同步的单据量特别大或者类似于权限授权特别复杂无法增量同步的无法通过WEB API进行同步的，那肯定只能通过DBlink方式进行同步了，那要满足多次拆分，那也必须让存储过程中调用DBLINK时也必须做到动态，也必须与前面的数据中心设计一样能做到动态访问，下次再拆分时不需要再修改任何地方则可完成多账套的同步

（4）   基础资料同步会比较多，并且有多少基础资料需要同步有很多不确定性，需要花费时间长，但时间也非常紧，设计时需要考虑尽量做到可配置来实现，这样会有很多好处，可以节省开发时间，也做到可动态配置，同时便于维护。

五、  需求分析和设计思路

1.   必须做好顶层设计，做到动态可扩展设计

（1）   账套信息必须动态可配置，每增加账套或者修改账套时只需要做配置即可，因此可考虑使用基础资料来管理，设计好后对外提供的接口也会自动产生

（2）   组织必须与账套建立对应关系，这个对应关系也可以变换和调整的，所以只要考虑在组织中能绑定配置的账套信息就行，并且需要把账套其他信息也带到组织里，其目的是为了将组织接口开发给第三方或者使用WEB API动态获取组织及组织对应的账套信息。

（3）   调用WEB API 前的登录统一使用密钥方式，并且用动态的方式，密钥文件的命名以“账套名称”进行密码，既便于识别是哪个账套的密钥，又方便跟数据中心的账套信息保持一致，保持动态，如果账套名称改了，只需要将密钥文件名字改为跟账套的名称一致即可，可用于第三方动态寻址的登录验证及账套之间同步前的登录验证

（4）   通过调研和分析，要满足多个账套跟一个账套的多个组织一样的使用，则必须很多

共享型基础资料，在一个账套创建后其他账套也可以公用，并且需要在保存、提交、审核、反审核、删除时完全同步，对分配型基础资料，在分配选择组织后，可以分配对应数据中心的对应组织，但由于到底有多少基础资料需要同步，有些是必须得同步才能满足业务需要及财务合并报表的需求，通过分析共享及分配型基础资料达到170个左右，因此工作量比较大，为了提升集成效率、后期维护的方便性、快捷性，因此考虑将基础资料同步也做成可配置，使用通用的插件来实现同步的功能，从而达到可以通过界面可配置来实现既灵活又可以动态添加需要同步的基础资料来完成集成

（5）   特殊场景必须使用DBLINK才能同步的，则访问时存储过程中需动态获取数据中心名称来识别是哪个账套的dblink,DBLINK命名时按此规则进行命名，这样可以保证满足账套动态增加或者修改，不用修改存储过程里面的调用方式。

2.   同步接口调用时如果标准接口不支持需总部提供私包解决

（1）   同步时需要包括主键同步，包括单据头和单据体的主键，但7.1 版本WEB API不支持同步主键同步，传主键认为是编辑状态，通过补丁解决，传参数时多一个参数，是否是编辑状态

（2）   基础资料同步时不支持的一些WEB API接口总部出私包解决

（3）   企业微信审批7.1版本不支持的，总部出私包解决

（4）   当前版本不支持批量修改触发保存的临时补丁解决

六、  动态设计方案

  1.     动态寻址方案

（1）   数据中心配置设计

“数据中心配置”设计为基础资料类型，可以进行动态添加和修改数据中心的配置，设计界面如下图：

字段说明：

•          字段包括：账套名称、账套ID、站点地址、APPSECRET、APPID，账套类型、数据库登录，其中数据库登录字段是特指Oracle数据库登录时需要制定是哪个用户，用于DBLINK 访问时动态指定，SQL SERVER 数据库不需要这个字段，APPSECRET、APPID 是WEB API访问时使用密钥访问方式时需动态指定的，账套类型字段主要设置在基础资料同步是主账套还是同步的账套，

特别说明：由于同步时需要同步包括主键一起同步，所以基础资料只能在一

个账套维护，同步到其他账套

        •         数据中心配置为一基础资料，用于组织这个基础资料动态指定数据中心使用

                  对外接口：

                      如果需要获取所有账套清单，则可以调用数据中心配置这个基础资料接

口，这个接口对外开放

（2） “组织机构”绑定数据中心

字段说明：

（1）   只需要选择“账套ID”,则可以带出相关账套相关信息，其他字段不可编辑，都是通过基础资料带出相关信息

对外接口：

（1）   “组织机构”这个基础资料需要对外开放接口，也是WEB API调用时供第三方系统调用的主要接口，可以根据组织ID动态获取数据账套地址和相关账套信息进行登录验证，也是动态寻址的主要接口方法

以上设计则可以满足动态寻址的需求，对外提供接口，可以根据组织动态找到账套的地址，并根据账套名称找到对应的密钥文件进行登录验证后则可以进入到对应的数据中心进行业务处理。

2.       基础资料动态配置方案

目前跨数据中心通过基础资料动态配置则可以完成数据同步属于设计创新，属于集团的项目中第一次尝试，利用动态领域模型中每个对象都可以动态抓出数据包，在保存、提交、审核、反审核时，动态调用WEB API，并将数据包动态转换为WEB API中需要的报文，并根据操作类型，调用对应的WEB API接口执行，因此只需要写一个通用插件来实现同步的功能

可配置界面设计如下：

设计说明：

（1）   这个是数据账套拆分非常核心的设计，主要是通过配置就可以完成对应的基础资料在保存、提交、审核、反审核、删除、分配等各种操作时即时进行触发和同步，同步时只需要挂一个通用插件则可以，既可以节省大量的集成工作，又便于后期维护，需要增加一个基础资料同步时只需要做配置则可以完成

（2）   配置时只需要输入对应的基础资料名称，系统会根据对应的基础资料对象动态加载所有的字段和字段映射，不用手动添加，如果想取消时删除默认的即可，配置也非常方便，配置时需要设置时公有型基础资料还是分配型基础资料，处理方式会不一样的。

（3）   操作类型也是所有的类型，可以动态设置哪些操作类型触发

（4）   不需要同步的字段则可以通过字段配置，那这些字段将不会同步到其他账套

七、  总结

1.   涉及到整个系统的方案时必须要考虑全面，需考虑各种可能性，必须要使用动态设计理念，能支持各种动态的变化因素，当变化后还能不修改任何代码，本身可配置就是动态的，需要从动态的配置里去获取各种数据，这样即使哪天的一些条件和里面的配置变了也可以不动代码

2.   需要利用好动态利用模型的数据包和元数据包，这样可以在很多场景可以巧妙的利用，让我们的设计可以动态，并且可以使用通用的插件来满足所有动态的单据或者基础资料来实现不同基础资料和不同单据直接的交互。

3.   当我们的WEB API不能满足同步的时候需要考虑DBlink这种实现方式，当然尽量使用WEB API来进行同步

4.   设计时需要多思考，需考虑其扩展性和与其他设计的关联性，比如DBlink动态配置及密钥动态访问则都利用了“数据中心配置”里的账套信息来实现动态，不用再单独设计配置。

5.   设计时还需要站在一定高度，考虑其他项目也能重用，这点非常关键。

mark