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

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

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

    这是个难点，处置这个问题的一般方法就是可配置化，比如采用流程引擎，智能表单，业务流程笼统，模板化等可配置化技术，但不能做得太过，不能最后做成了二次开发或者干脆就是一个新的开发工具（典型的如SAP的系统）。大部分的目的用户都没有这个开发才干，因而必需停止平衡。比如，我经历过一家公司，我们做到页面的全配置化显示，看起来节省了前端开发和后端开发的工作量，但由于配置参数太多，最后反而增加了很多配置学习本钱，配置使用本钱，以及配置无法满足业务时的定制本钱，整体上的本钱反而不划算。后面这种形式不了了之，白白消耗了几百万。
    简单易用和专业复杂性之间的平衡，也是个性化和通用性的之间的平衡，假设太复杂或者需要二次开发显然是不现实的，为理处置这个问题，行业领域垂直细分就是一个不错的选择，毕竟领域越细分通用性就会好些。
§3）分布式架构的切割维度和粒度（事务性强）

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

    只要是管理系统，规范化是最根本的，规范化的目的是支撑业务的连续性、一致性。这里采用的就是对业务数据必需停止分类分层，对数据归属规则和权限架构结合最大水平的减少权限设计的简化和一般化。
§5）其它：数据库使用原则，数据隔离级别等

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

  对于SaaS应用，还面临多组织（集团形式），多语言，多时区的问题，多组织相对来说比较好处置，利用企业规范化和业务数据归属及权限就可以处置；多语言处置的根本原则就是配置数据库化，传统的程序多语音包可以做到数据库配置层，当然系统架构底层最好是配合做一些规划；多时区的问题实质是个时间规范的问题，这个是个时间技巧处置的事情，相对比较简单。