转-中国式SaaS技术架构

架构层面做的强大，满足各个租户的自定义和系统集成。

　　中国呢，过去的3年已经证明面向中小企业、创业企业基本是不靠谱，所以从去年下半年，大家都纷纷杀入中大型企业、大型企业。这些中国企业，要么要求在他们的私有云中部署，要么要求在公有云为他们开辟一个专区专门独立部署，而且都要求和他们现有的内部ERP软件统一用户账号登录、应用逻辑打通、数据打通。

　　这就是中国的现实，那如何满足中国的这种需求呢？于是，这就出现了中国式SaaS技术架构。

　　一、客户端UI

　　不同的岗位工作环境有不同适用的应用技术：

　　1、对于一线现场（如生产制造、仓储物流配送），一般采取扫码POS或微信小程序，扫码后简单操作几下就把业务关键点记录了下来。

　　2、对于一线零售店面收银，现在大多数白牌平板App

　　3、对于来回跑中间分销、渠道、采购、督导的外勤，基本是手机App来处理业务

　　4、对于坐在后端的运营人员、人事法务财务，基本用的就是台式电脑Web应用来处理业务

　　二、后端业务逻辑层

　　因为客户端是不同岗位、不同素质能力水平、不同业务重心、不同工作环境，所以功能不一样、用户体验不一样，所以后端的服务层业务逻辑也都不一样。

　　这层因为涉及到客户端接入，所以需要API网关中间件，因为比较轻（因为还有一层公共业务逻辑处理层），所以采取微服务中间件（如SpringCloud），这些不同的微服务都打包在一个个的Docker中，为了快速弹性启动扩容。前面有API网关中间件可以做分流限流、路由导流，这样后面微服务容器怎么扩容，对前端都透明。

　　但是总有一些业务逻辑是这四种端应用都要处理的，所以还得分出一层叫做公共业务逻辑处理层。这些公共业务逻辑处理层按功能职责也分成一个个的服务，放在Docker容器中，受Swarm或Kubernetes集群管理。

　　三、分布式技术中间件层

　　API网关中间件就属于这一层，只不过客户端来的请求都首先经过它再路由到业务逻辑微服务。

　　另外一个重要的分布式技术中间件是数据传输。可以采取Kafka分布式消息队列来做数据管道。

　　我们也可以使用ZooKeeper分布式中间件进行各种后端处理服务的配置以及执行调度。

　　这些分布式中间件也都部署在Docker Swarm集群管理下，用API形式供上下层调用。

　　四、数据存储层

　　有些数据需要放在内存里为了快速查询，所以我们需要用到分布式Redis集群。

　　有些数据需要持久性放在关系型数据里，我们可以用MySQL关系数据库。为了分布式存储，我们可以在MySQL之前再放一个MyCAT分库分表分布式中间件。为了读写分离提高性能，我们可以在MyCAT之前再放一层MySQLProxy，用于主备读写分离。

　　有些数据是文件形式，如图片、音频视频，我们可以用分布式文件系统和对象存储系统来存放。我们还可以使用CDN技术来做这些静态文件的分发加速。

　　有些数据是特殊的数据结构，如时间序列数据（IM消息一般是这样特点）、如图数据（社交网络一般是这样特点）、如大文本数据（点评评论一般是这样特点），为了加快这些特殊结构的数据存取，我们可以用时序数据库、图数据库、文档数据库等等。

　　这些数据库引擎可以为了加快性能，部署在物理服务器上。而这些数据库引擎存取的数据，可以放在块存储云硬盘卷上。

　　五、主数据模块

　　这是个模块，会用到后端业务逻辑层、分布式中间件层、数据存储层的各项技术。

　　这个模块主要有两大功能：

　　1、用户登录验证。在API网关这样的纯技术中间件基础上，我们还需要研发一个用户登录网关，用于辨别不同的企业用户登录进来，进行身份认证、路由指定。这个用户登录网关需要和API网关进行配合使用。因为登录是每个用户访问的第一步，这块最容易会成为性能瓶颈，所以要尽量做到高性能编码、分布式扩容/分流负载均衡。

　　2、主数据管理。主数据管理有以下主要动作：主数据同步复制、主数据分发、主数据更新（有先后顺序有存取锁问题）。所以主数据需要独立出来，供各个系统使用。为了防止主数据存取成为瓶颈，数据库这块也需要注意主备读写分离、分库分表、可方便分布式部署。当然也需要有后台图形化的主数据管理系统来做人工的干预维护。

　　六、大数据仓库

　　刚才以上咱们讲的都是业务逻辑处理需要的技术以及架构堆砌模式，对于报表统计、历史查询、综合查询、商业指标对比分析，咱们必须把这些工作放到大数据套件中来处理，和真正快速业务处理的系统分开。

　　不仅仅是要计算资源分开，还要存储资源也分开。因为对于大数据，存储容量要大（但不一定存储访问性能要高），内存要大（要进行大量数据取出进行计算），CPU性能要高（要密集计算）。所以对于统计、查询、分析这些功能，服务器云主机和云存储都要和应用业务处理分离。

　　分离后，就需要从应用业务处理系统中抽取数据。

　　所以，对于数据抽取层：我们有一系列的ETL工具，还有数据爬虫引擎用于爬内外静态数据，还有用Flume、Logstash、Splunk收集IT资源日志和应用系统运行日志。

　　抽取来的数据可以放在大数据仓库中，我们可以采用Hadoop HDFS、Hbase、Hive等等开源中间件。

　　要计算处理时，我们可以在YARN或MapRedurce计算调度框架下使用Spark、Storm来进行内存计算和流式计算。

　　处理后的数据，我们可以用presto查询，我们也可以用ElasticSearch来搜索。

　　最后，我们使用一些可视化工具把结果用图表形式输出出去。

　　七、最后总结

　　按照这样的技术架构搭建好后，每一个客户要在公有云上专属独立部署，那么给它用DevOps工具新启几个服务层Docker，如果公共业务逻辑模式也要变化，那就新启几个公共业务逻辑Docker。毕竟我们有分布式用户登录验证网关和API网关，所以不管是公有云专属部署还是私有云部署，都没问题。

　　对于主数据管理模块，因为也有UI层、逻辑层、数据层，所以主数据这些各层的代码和数据和中间件，可以打包成一个部署单元，用一套专门的DevOps工具及脚本进行自动化部署、配置变更、升级。

　　对于数据层，我们有KV分布式数据库、分布式关系数据库、主备读写分离中间件、分库分表中间件、CDN分发、时序数据库/文档数据库/图数据库、我们确实需要在API网关路由层面用DevOps工具及脚本、集中配置中间件Puppet来做到自动化部署扩展、配置变更、升级。这样不同的企业指向了不同的分布式数据库引擎地址和分布式数据库存储卷。这样就方便了既能做公有云专属部署又能做私有云部署。

　　但要记住，这样的架构比较适合中国式SaaS。对于国外老美的SaaS，人家一开始目标就是要满足大中小不同规模客户，要满足全世界企业，所以如果做成中国式SaaS技术架构，那以后会越来越麻烦。所以老外人家的技术架构是一开始很难设计与搭建，一开始的维护也很麻烦（需要编写很复杂的自动化运维工具与脚本），但随着规模越来越大（比如几十万甚至几百万家企业），那老美的SaaS技术架构就显示出复杂性优势了。

　　不同发展阶段，使用不同的实现技术架构。你也不用梦想着用一套架构逐步演化和层层搭建，就能逐步从满足中小企业扩展到满足跨国企业。当然作为一个特定的SaaS企业，谁也不能既能满足了创业企业的需求，又能满足跨国公司的需求。所以想想国内如用友这样，既有畅捷通产品与架构、又有U8产品与架构，又有NC产品与架构，分而治之就好。连SAP，也还能有SAP ERP套件和Businees One中小企业两套不同产品线不同技术架构。