中国式SaaS技术架构

2017-03-02 14:09:00




                                                     老外是多租户SaaS技术架构,也就是说,一套分布式应用代码、一套分布式数据库存储,

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


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中小企业两套不同产品线不同技术架构。


Keep IT Simple. 让信息技术更简单

联系我们
400-0800-5580551-62837292
在线服务
QQ:3020438181
我们在这儿
本部:合肥市高新区科学大道5f创业园B座2楼 上海办事处:上海浦东南路100号民生大厦38层 南京办事处:南京市燕江路201号数码港235室

COPYRIGHT © 2018 Simpo辛普科技  皖ICP备14019348号-2  ISO27001:2016信息安全认证