toB的SaaS平台研发难点和应对策略

§1）管理，技术和业务的平衡；

      SaaS平台对于业务架构师的要求很高，需要在管理、技术和业务之间取得一种平衡。我的建议是以管理为目标，进行技术和业务架构的适应和匹配。因为本质上，SaaS平台本身就是大数据，而大数据的设计还是坚持“ 面向应用（业务）架构”原则。另外，系统架构或者高级研发人员参与产品需求分析和业务架构应越早越好。

§2）通用性和个性化的平衡

    这是个难点，解决这个问题的一般方法就是可配置化，比如采用流程引擎，智能表单，业务流程抽象，模板化等可配置化技术，但不能做得太过，不能最后做成了二次开发或者干脆就是一个新的开发工具（典型的如SAP的系统）。大部分的目标用户都没有这个开发能力，因此必须进行平衡。比如，我经历过一家公司，我们做到页面的全配置化显示，看起来节省了前端开发和后端开发的工作量，但由于配置参数太多，最后反而增加了很多配置学习成本，配置使用成本，以及配置无法满足业务时的定制成本，整体上的成本反而不划算。后面这种模式不了了之，白白耗费了几百万。

§3）分布式架构的切割维度和粒度（事务性强）

    ToB的业务一般来说事务性特别强，单纯的采用微服务或者传统系统模式都不是特别好，我的建议是根据 二八原则，为解决80%的问题可以采用简单的分布式数据存储模型，其它20%部分可以采用微服务这种架构。分布式架构中涉及到分割维度和粒度，根据自身的业务特性去考虑，维度不要过多，最多3维，粒度以最大化事务同库为基本原则。应用无状态是基本的原则，类似于内存数据库的东西尽量不要用，这种方式不利于分布式负载均衡的处理。我们的产品采用的是我们自己研发的三大模型（分布式计算模型，分布式部署模型，分布式数据存储及访问模型），很好的解决了这些问题。

§4）标准化，一体化（业务连续性，一致性）

    只要是管理系统，标准化是最基本的，标准化的目标是支撑业务的连续性、一致性。这里采用的就是对业务数据必须进行分类分层，对数据归属规则和权限架构结合最大程度的减少权限设计的简化和一般化。

§5）其它：数据库使用原则，数据隔离级别等

数据库使用的原则就是数据库只进行数据的基本操作，业务逻辑不要放在数据库（比如用存储过程，视图等）。而数据隔离基本上都是需要支持表隔离，数据库隔离，物理隔离三种级别。