【干货分享】——宜搭核心设计和思考

简介： 宜搭首席技术官谈宜搭核心设计和思考，宜搭平台是搭建企业协同办公领域应用的PAAS平台，自今年3月上云以来，宜搭已持续为近30位合作伙伴助力解决方案的提供，服务客户涉及新零售、医疗、银行、制造、酒店等多个领域。这里总结下最近两年的企业应用实践经验，分享下宜搭的设计以及背后的思考，欢迎大家讨论。

产品核心特征

　　产品核心特征总结为5点：低门槛、一站式、泛业务、高定制、高集成。

1. 低门槛
2. 一站式
   　　由于是应用开发的平台，目前开发平台最直接的方式就是写代码。但是我们需要意识到，由代码构建的系统就是对客观运行的业务系统规律的一种描述方式，这种方式并不是唯一的，只不过目前受制于生产力或者说技术工具亦或是技术手段，才导致目前编码几乎是唯一的开发平台的有效方式，也就是形成这样的链路：业务需求 --> 开发编码 --> 应用系统。如果我们可以把中间的开发编码环节替换掉，变成更容易使用的门槛更低的方式，即：业务需求 --> 开发平台 --> 应用系统，门槛的降低将支撑起更多的用户，此外操作的简化将带来效率的提升与错误率的降低。因此，宜搭平台自创建开始，就是定位给无编码基础的用户，希望可以附能于非开发岗位的业务同学，帮助他们去实现自己的业务系统。这里的用户特制使用宜搭平台进行开发的用户，而宜搭平台开发的系统面对的用户是不会变的，就是业务同学。
3. 一站式
   　　承接用户定位，要求平台必须提供一站式的能力，包括研发流程支撑、开发环境支撑、运行环境支撑、监控运维支撑等等。研发流程支撑，传统的为：提交需求—>确定产品方案—>评审—>开发—>测试—>验收—>上线，横跨多人甚至多个团队部门，往往还需要立项来管理，研发上也需要考虑设计、安全、适配性等等问题，使用宜搭平台之后，这些工作均可以交给一个人来完成，效率大大提高。开发环境支撑，传统的JAVA WEB项目，需要自己使用框架编写代码，并申请数据库、应用服务器、缓存、消息队列、文件存储等等来进行支撑，成本较高，并且使用这种方式编写的代码无法跨系统复用。运行环境支撑，传统的需要运行在自己的服务器上，而使用宜搭平台之后，由平台提供，背后对用户完全不可知，并且后续也提供了丰富的升级可能。监控运维支撑，传统的方式，业务数据需要自己埋点监控，而由宜搭平台提供之后，全部交由平台管理，在平台统一查看。
4. 泛业务
   　　由于不指定支撑的业务领域，因此要求平台的模型更加的抽象。抽象始于“特殊”归于“一般”，要求宜搭去收集大量的场景，提炼出背后的一般规律，精炼出模型和逻辑。宜搭在初始阶段，调研了行政、财务、法务、IT、资产等等业务，决定使用页面、逻辑、数据这三块作为底层的核心模型。经过2000多个应用的实践打磨，基本证明了这条路的可行性。
5. 高定制
   　　由于需要支撑各个领域的业务，并且即使是相同领域的相同业务场景，其需求受到时间地点人员等等制约，也可能是不一样的。如何设计一个高定制的研发平台，其实就是在可变性和封装之间获取一个平衡，封装程度越高，用户使用成本越低，但是其响应变化的能力越差，以国外产品infor为例，其将沉淀了数十年的业务领域封装为领域模型，开放出来的仅仅是预先设置好的数据属性字段配置以及业务逻辑扩展点，假设这个业务领域发生了变革，那么影响是致命的。而如果放弃了领域模型的封装，那么可变性必然会提高，但是用户的使用成本将大大上升，并且无法实现业务模型的复用。为了响应用户更灵活的需求，宜搭在设计上选择了后者，并且已经想到了针对这个问题的解决方案，就是分层，下文会展开描述。
6. 高集成
   　　企业软件架构设计阶段里面，有一个重要的考虑环节就是架构迁移规划。假设宜搭平台已经足够成熟，成为了企业应用搭建中台之后，老的系统迁移到新的系统架构也是需要时间的，如何一步一步安全平滑稳定的迁移，中间的过渡方案是什么，都是需要考虑的问题，更何况宜搭平台还处在产品的创新摸索阶段。在DT时代，要求我们在数据和应用层面打通，提供一体化的体验，实现各个系统间的连接，因此就需要强大的开放和集成能力。开放指的是平台提供标准，供其他系统调用，而集成指的是平台调用其他各个系统，这里面就需要用到依赖倒置的思想，将需要集成的其他系统的服务规范起来。

产品架构

　　针对上述对产品的思考，宜搭的产品架构设计如下：

1. 应用使用者
   　　宜搭提供了对内和对外两个版本，内部版包括了正式、外包和生态化公司员工，外部版包括了钉钉和第三方企业用户。再细分一下，宜搭平台的用户被划分为两类：应用管理员和应用访问者。应用管理员即是搭建应用的用户，而应用访问者指的是搭建完成的应用的最终使用者。
2. 输出端
   　　目前宜搭未提供自己的APP端，使用阿里内外以及钉钉来承载，此外也有自己的H5页面。
3. 宜搭平台
   　　分为两态，即管理态和运行态。管理态仅支持PC访问，提供给应用管理员来创建编辑发布应用；运行态支持PC以及移动端访问，提供给应用访问者即真正的业务用户。
4. 基础依赖
   　　宜搭平台提供一站式的解决方案，集成了框架、中间件、等诸多基础服务。

　　针对5个产品核心特征，在产品设计和技术设计上，宜搭也有自己的思考和打法。

1　. 低门槛
1.1. 认知模式
　　目前我们去构建一个软件系统，领域建模方法推荐的方式就是使用一致的语言去描述一个一致的模型，让产品、开发和测试都可以达成共识。而后根据这个一致的模型即领域模型，去实施开发方案。随着阿里巴巴中台化战略在集团内推广以及在国内的影响力，领域建模的重要性也得到了越来越多的共识。但是对于不具备编码基础的业务人员，他们并不具备领域建模的能力。因此，在项目初始阶段我们进行了评估，宜搭平台决定先采用表单驱动的方式来进行业务建模，这个方式更加符合我们应用管理员用户的认知。随着平台的发展，宜搭平台承担的业务也越来越复杂，而不少业务人员自身，已经具备了建模甚至是编码的能力，因此宜搭平台考虑下一步，新增领域视图建模范式，作为目前表单建模范式的升级。这个也启发我们，随着业务人员自身的更迭升级，当编程能力已经成为类似英语的基础技能的时候，我们的产品形态会变成什么样子呢？
1.2. 可视化
　　作为最直观最高效的表达方式，可视化已经成为了产品的标配。目前宜搭实现了页面绘制、流程编排、数据呈现上的可视化，管理员用户通过拖拽和选择等方式，就可以实现整个应用的搭建。但是如何把页面、逻辑和数据，完全可视化的展示在用户面前，仍然是一个十分困难的课题，尤其是逻辑这一层，以流程为例，一个人工节点就有10+以上的配置项，并且用户不可见的内置底层配置项还有不少，且可能不断地演化升级。因此如何让用户精确地将自身的操作本身和背后的运行逻辑建立完全1对1的映射关系，是需要解决的关键问题，也是宜搭下一步重要的努力方向，即新增业务领域层。
1.3. 简洁
　　在用户界面设计上，简洁是一个一直奉行的原则，让用户仅感知到最核心的内容，随后在一层一层引导用户来完成所有的操作。宜搭平台奉行的简洁原则，还有一层“精简”的含义，在第一个版本直接去掉了大量的已有功能，仅保证了一个最简系统的闭环。这样做大大降低用户门槛的同时，也加速了系统的上线，此外通过倾听用户的反馈，也可以辅助我们去评估需求的优先级，进而指导我们进行功能迭代。
1.4. 快捷操作
　　针对用户的常用且配置相对繁琐的操作，宜搭封装了快捷操作方式。除了快捷键的使用之外，在功能上宜搭也提供了关联表单组件功能来实现页面组件之间的联动，提供了关联表单数据和条件数据关联来满足不同数据源之间的关联需求等等。

2　. 一站式
2.1. 自动化
　　当用户定义完自身的页面逻辑以及数据后，自动帮用户完成整个运行环境的部署。页面使用统一标准的schema语言定义，前端页面选择react框架渲染，每一个最小业务单元封装为组件，在PC端使用H5页面渲染，在移动端结合app特性，调用对应的native api进行渲染适配，提升用户体验。中间的逻辑层，目前尚未隔离和独立部署，所有的业务逻辑全部运行在共同的服务器上，这块是可以结合集团基础设施等团队来共同协作的，以提供高可用的服务。最底层的数据层，目前也均是采用统一的存储引擎存储，不过这块宜搭使用了分层的数据架构，因此设计上预留了扩展的可能，可以进行改造，使数据层支持物理上的独立部署。
2.2. 多租户
　　目前宜搭使用的是逻辑上的标识，将应用服务和应用数据完全隔离开。就像上文自动化中提到的，后续宜搭会考虑支持物理上的隔离，做到应用独立部署和数据独立部署。由于使用了统一的平台框架来进行开发，方便用户开发的同时，也在无形之中添加了约束规则，因此降低了应用弹性扩容、服务治理、数据切换迁移的难度，为后续部署架构的升级提供了极大支持。

3　. 泛业务
　　不特指业务，因此目标可以支持所有的业务
3.1. 通用模型
　　表单、逻辑、数据为核心的模型，来源于对业务的理解和抽象，也比较符合大众直观的感觉。但是这个概念太大，在实施上，宜搭寻求了最小的业务闭环，表单模型包括了组件、布局样式、以及常用的事件和行为；逻辑模型一期仅支持了流程，后续才逐渐开放了公式、脚本、规则的能力；数据模型则直接读取表单模型的字段，自动优化字段类型和索引，而后基于此，提供了单数据集数据在线聚合分析和展示的能力，多数据及关联以及复杂的在线离线数据抽取转换清洗功能陆续上线中。
3.2. 分层思想
3.2.1. 领域模型层
　　上文提到，宜搭平台放弃了领域模型的封装，直接暴露更底层的能力，使用业务的灵活性换取了业务的复用性。宜搭马上会上线的应用模板市场，可以在一定程度上解决复用性的问题，提升搭建效率，但是这将导致领域模型被频繁的复制修改，好比一段代码被在系统中出现了很多处，并没有本质上解决问题。解决这个问题的思路方法就是增加领域模型层，同时宜搭平台的用户角色也将进行调整，用户角色在之前的应用管理员，应用访问者基础上，在增加领域模型管理员。领域模型管理员，使用现有的宜搭系统来搭建领域模型，而应用管理员则可以直接使用搭建好的领域模型进行业务开发，这个模型封装了绝大多数的业务规则，仅暴露了必要的配置能力。这种分层的方式，优雅的解决了业务灵活性与业务复用性的问题。
3.2.2. 数据层
　　宜搭数据层也使用了逻辑和物理存储分离的架构设计。分离出逻辑层是因为宜搭底层可能使用多套混合的存储模型，来支持泛业务的场景，逻辑层需要去路由判断目前请求命中的底层存储引擎是什么，进而去请求物理存储层。

想看完整文章内容：点击这里

原文出处：阿里云大学开发者社区