转帖:技术类干货:浅谈SaaS服务平台设计

根据Gartner 2015年的技术成熟度曲线,SaaS是未来HCM软件的大势所趋,处于稳步爬升的阶段。
  这里不赘述SaaS的各种优势,像体验良好、灵活部署、按需付费、快速改进等。本文重点说明优秀的SaaS产品(特别是HCM产品)是如何进行技术设计以建立这些优势的。
  相比之下,如果做了糟糕的技术设计,就如同把产品和服务建筑在流沙之上,岌岌可危。

  经典的计算机体系结构里,底层是硬件,中间是操作系统,上层是应用软件。
  可以把SaaS架构与经典架构做一个映射:底层是虚拟平台层,中间是存储和服务层,上层是应用逻辑层。下面按照自下而上的顺序逐一论述。
  虚拟平台层
  摩尔定律是计算机世界里最重要的一个定律。根据摩尔定律,今天的处理器的性能是1980年的处理器性能的100万倍以上,今天一台智能手机的计算能力超过1980年的IBM大型机。
  得益于计算能力的指数增长,虚拟化的IaaS云服务大大降低了平台软硬件的部署成本,从而促进了SaaS服务的兴起。
  国外知名的云主机厂商有AWS和Linode,国内知名的云主机厂商有阿里云和腾讯云,各有优势。操作系统方面,Windows、Linux、Unix是常用的选项。考虑到世界上80%以上的云服务都跑在Linux系统之上,而且Linux免费开源,Linux当然是较佳选择。
  接下来要考虑的就是技术栈的问题。SaaS是轻前端重后端的系统,通过把复杂性从终端转移到云端,一方面保证用户端良好的体验,另一方面确保云端强大的进化能力。SaaS的技术核心在云计算,技术框架既要考虑开发效率,也要考虑程序性能,还要兼顾语言成熟度和开源社区支持。
  老一代的框架有Widnows的.NET和Java的J2EE。基于Windows的架构基本得不到开源社区的支持(可见程序员们对Windows多不感冒);Java架构成熟但是开发效率低,不太适用于快速迭代和敏捷开发。
  新生代的框架包括Mean和Go。基于Nodejs的Mean架构发展迅猛,采用Java打通前后端成为统一的全栈开发语言,但是Nodejs在大数据和高并发下的表现有待进一步观察;Go是Google力推的后端多并发编程语言,但由于是全新的语言,国内在工程师的深度和广度上面都不太能确保。
  中生代的框架包括Lnmp和Ruby on Rails。经典的Lnmp是世界上最广为使用的Web服务框架,开发效率高,得到广泛验证稳定可靠,而且开源社区活跃。相比之下,Ruby在稳定性和社区支持方面稍逊一筹。
  Lnmp架构在360和新浪微博得到广泛应用,承载了每日亿级PV的访问量,Facebook的后端主力框架也是Lnmp。兜行的技术框架同样采用Lnmp。
  存储和服务层
  数据是企业最核心的信息。特别是HCM系统,能够得到大量的员工数据,对于数据分析的要求非常强,如人事档案还面临数据字段的动态变化,这就要求HCM系统在数据的存储结构设计时要充分考虑这几点:
  1、数据结构的灵活扩展
  2、读写的效率与可靠性
  3、数据库CAP设计的平衡
  面临快速变化的用户需求,传统的强schema模式数据库常常心有余而力不足。
  比较激进的做法是直接升级到无schema的no-SQL数据库,比如MongoDB和CouchDB。但是no-sql数据库在带来灵活性的同时,也带来了一些副作用,比如临时表空间占用过大,不定期的垃圾回收机制导致性能抖动。
  比较稳健的做法是基于稳定成熟的关系型数据库,预留出动态字段,如mysql从5.7版本起原生支持JSON数据类型,或者采用EAV设计模式,把原本按列保存的数据转换成按行保存。
  固定字段长度的EAV表,在操作效率和稳定性上要高于no-sql数据库。兜行的数据库表设计里面,大量采用EAV模式。
  缓存和读写分离是常用的提高读写效率的方法。比起Memcache,Redis因为支持内存数据结构,在缓存处理上更为灵活。我们可以利用Redis实现KV、消息队列、列表、Hash,甚至用Redis实现锁的功能。
  更新缓存的Design Pattern有四种:Cache aside, Read through, Write through, Write behind caching。出于性能考虑通常选择Cache Aside Pattern,出于一致性考虑通常会选择Write through。
  以兜行为例,后台管理用的是Read through/Write through,前端访问用的是Cache Aside Pattern。
  HCM系统需要对数据做大量分析工作,这些工作涉及到两类科学计算:统计分析和数据挖掘。
  以考试为例,需要做的统计分析包括:较高分、较低分、平均分、方差、区段、每道题目的正确率,每个选项的选择比例等;可以做的数据挖掘包括:成绩预测,自变量与因变量的相关性等。
  值得一提的是,企业的人数通常不会超过几十万人,大部分时候可以把所有数据导入内存,实现in-memory computing,既提高了速度又降低了分布式计算的复杂度。对于少数数据量极大的场景,可以把任务吐到map-reduce平台完成。Python以丰富强大的科学运算库著称,是完成这些工作的得力工具。
  在服务层除了科学计算服务,SaaS厂商通常还要支持CDN服务,以确保用户快速访问到网络上的资源。
  对于HCM产品,涉及到音视频的课件和office文档课件,所以还必须提供视频编解码服务和文档转换服务。另外,为了把消息及时通知到终端用户,服务层还要支持消息推送,邮件通知,短信通知等多种机制。
  SaaS服务的可靠性是很重要的指标,要达到5个9的可靠性水平(即99.999%的时间可用),除了云主机自身的稳定,需要设计相应的应用监控、负载均衡和容灾机制。
  LVS可以用来实现负载均衡,避免单点故障。同时应用层的心跳监测和告警机制,也能及时发现故障。有趣的是,不少SaaS产品做的就是应用监测,比如New Relic,听云APM和OneAPM。为了防止系统级的故障,数据和程序的镜像应该在多处备份。
  应用逻辑层
  MVC是经典的程序设计架构,其实产品设计也遵循同样的思路。把手机端/电脑端/网页端等用户端想象成V,用户在界面上操作;把云端想象成M,做存储和计算;把client和server之间的通信协议想象成C,完成控制与反馈。
  前面说的内容大多与M有关,下面先说说C,即通信过程。
  SOA和MicroService之争一直是很热的话题。求同存异地看,它们共同传递的信息是:把功能和服务内聚成模块,模块之间通过标准的接口进行通信,去掉大而全的core,变成独立运转的蚁群。听起来是不是和面向对象的思想很相似呢?
  抽象和内聚的设计模式是普适性的。对象之间通过函数调用来提供服务,而SOA和MicroService之间通过网络请求来提供服务。据说Bezos在十几年前就要求亚马逊的所有产品都以网络API形式提供服务,这是最早的SOA吧。
  最常用的网络请求是Http协议,Rest API是基于Http协议的一组规范,明确了CRUD四种操作对应的Http请求格式。工具型SaaS厂商的服务,很多以Rest API的形式提供。
  HCM系统也会大量涉及到与企业内其它系统,如OA、CRM、ERP的对接和数据打通,基于Rest API的服务接口,就是不同系统间沟通交流的语言。
  最后说说V,前端框架。
  前端是技术世界里变化最快的角落。广义来看,ios、android、windows pc、web、微信h5都是前端。
  前端是用户第一眼看到产品的地方,如何改善用户体验是前端最关心的问题。因为用户看得见摸得到,所以展现层的修改和调整会特别频繁,如何减少重复工作快速改进,这也是前端框架要解决的一个重要问题。web app和native app是前端的两种形式,目前看来各有优劣。
  web app的优点是开发速度快,云更新实时生效,不用维护历史版本。缺点是每个独立页面都要发起若干个http请求,交互滞后明显,体验较差。新兴的前端框架重点就要解决体验问题,像Angular框架的较大优点就是减少了页面请求。
  native app的优点是体验好,缺点是产品大量版本碎片,向下兼容维护工作量大。对于安卓手机,还有绕不开的适配问题。
  较优的解决方案是Hybrid模式:在native里面嵌入若干的webview页面,在效率和体验之间找到平衡点。
  相比传统的On-premises系统,SaaS系统的架构发生了巨大的变化,分层和模块化更为清晰,组合方式也更为复杂。这些变化,以及依然进行中的快速进化,会带给用户越来越好的产品和服务。
  作者:牛透社特约撰稿人

  • 0
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值