转-中国式SaaS技术架构

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

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

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

　　1、客户端UI

　　不一样的岗位工做环境有不一样适用的应用技术：

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

　　二、对于一线零售店面收银，如今大多数白牌平板App

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

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

　　2、后端业务逻辑层

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

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

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

　　3、分布式技术中间件层

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

　　另一个重要的分布式技术中间件是数据传输。能够采起Kafka分布式消息队列来作数据管道。

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

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

　　4、数据存储层

　　有些数据须要放在内存里为了快速查询，因此咱们须要用到分布式Redis集群。

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

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

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

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

　　5、主数据模块

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

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

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

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

　　6、大数据仓库

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

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

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

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

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

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

　　处理后的数据，咱们能够用presto查询，咱们也能够用ElasticSearch来搜索。

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

　　7、最后总结

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

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

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

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

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