BaaS后端即服务 - 通往中台架构之路
BaaS代表第二代云服务,相对于AWS、阿里云等公有云（IaaS，PaaS）是第一代云服务，通过广泛部署云数据中心解决了开发和运维系统不需要管理服务器的问题,BaaS则在第一代公有云数据中心基础之上，对云计算资源进一步封装、简化与优化，提供开发、运维和服务的一站式云服务。
这就是所谓BaaS（后端即服务）模式的兴起，BaaS将公有云数据中心资源根据前端应用场景打包，通过简化的调用接口提供给开发者使用。通过减负，开发者得以集中精力于用户的研究、APP软件的创意与设计以及移动端的应用开发即可，能大幅简化开发过程、周期、人员与资金投入，从而降低成本，并能把移动APP应用快速推向市场。
以我的理解，BaaS架构的发展趋势是解决业务的开发效率问题。
所以本系列文章主要介绍BaaS的发展和架构特点。
本文是BaaS相关架构实践的起始篇，主要介绍目前软件开发模式的发展趋势，目前BaaS的生态等综合性内容，然后用几个篇章详细介绍BaaS的概念，发展趋势，如何实践BaaS架构。
最后我们在探讨如何用BaaS的思路来，结合现有的技术体系来构建实施中台。
《BaaS后端即服务 - 通往中台架构之路》 - 本篇会介绍相关的背景和总体思路。
《BaaS后端即服务 - 概念篇》- 介绍BaaS的概念，在云架构体系中的定位。
《BaaS后端即服务 - 分析篇》- 介绍当前BaaS发展的趋势和主流BaaS平台功能的对比。
《BaaS后端即服务 - 中台篇》- 介绍如何用BaaS的思路来构建中台系统，是否可以成为中台建设的基础架构之一。
1. 外面的世界很精彩
如果放在整个互联网来看，在这个移动互联网时代，火热的创业潮兴起，O2O，物联网，互联网金融， 一个想法从产生到实施，也许只有几个月的时间，否则就会有类似的产品推出， 在短暂时间内推出产品，去市场检验，从而占据市场，对创业者来说，都是一场要快速执行的战役。可以说这是一个激烈竞争的市场，在这样的市场，只有高效，有效的模式会成功的存留下来，而BaaS的架构就是诞生发展于移动互联网这个熔炉中并快速发展起来，成为云架构体系中重要的架构思想之一。
对创业开发者来说，成本和效率是最需要关注的两个方面，第一他们缺少技术的积累，第二他们需要很低的成本去验证他们的模式，从而成长起来。这些云服务提供者成为他们最好的选择。
当创业技术团队去实现他们的技术架构实现时，会欣喜的发现，他们需要的一些通用功能有专门的技术创业型公司为他们提供服务，这些服务以云服务的形式对开发者开放，他们或者提供某个领域的功能，或者提供全面的功能，可以说正在慢慢形成一个云服务生态，为创业者提供各种技术服务。
让我们假设自己是一个O2O的创业的CTO，准备就一个O2O的想法，开发出一个业务平台。 在这个移动互联网时代，基本会需要移动APP和web的功能，那么一下的问题我们需要解决：
服务器部署维护
APP和Web网站开发
后端服务开发
平台功能：
认证和授权
文件存储
推送和通讯
地图功能
支付功能
社会化分享
验证和安全
智能识别
搜索
用户行为分析
...
业务功能
活动管理
最新动态
...
当这些问题被规划出来后，作为CTO，你就需要招聘后端工程师，前端工程师，IOS，Android工程师，运维工程师等，然后针对平台的功能，会发现每一个都是需要去设计，实现，其中有些功能在技术上挑战很大，比如搜索，地图，支付这样的功能，独自快速实现这些功能对创业公司来说是需要很大成本（时间和开发资源）才能完成。
但同时，随着在技术市场上调研， 会发现这些基础的服务，有专门的公司提供解决方案，这些方案可以被集成进来，从而节省开发成本。比如：
推送通讯领域，有极光推送，个推，环迅，融云，UDesk，Bmob，meChat等等
地图功能，有百度地图LBS，高德地图
支付领域， 除了支付宝和微信支付自己提供的服务外，Ping++，现在支付等提供了更集成易用的整体支付解决方案。
验证和安全， mob，云之讯提供了短信验证等功能。
社会化分享，友盟，jiathis等
...
基本在每个常用的功能领域，都有技术创业公司为此提供专门的服务，这些技术公司通过敏锐的商业触觉，快速响应技术市场的需求，从而也推动了新的技术架构服务的诞生。通过给创业者更多的方案选择，由此创业者可以直接使用这些服务来实现自己的业务需求，从而能快速的将产品平台开发出来给最终用户使用。
可以说这些业务和技术创业公司鱼水情深， 形成了生态互补，通过吸引创业公司使用它们的服务，技术平台公司获得更多的数据，创业公司则获得了免费的越来越好的服务。技术平台公司通过竞争，会越来越完善他们的服务，给开发者更好的开发体验，从而自己在领域中获得龙头地位。
这些技术平台公司在这个移动互联网，云计算的时代，通过将某个领域的功能封装成服务来获取开发者用户，他们的这种模式，就是云架构最近几年飞速发展起来的BaaS架构。
2. 我们的世界有点无奈
2.1 系统繁多，不能轻装上阵
技术部目前所有开发人员与系统相比太少，为什么有这么多系统，都起什么作用，
于是我们决定用领域模型分层的方式去梳理这些系统：
然后我们又发现，好像我们没做太多事情啊，支持的业务可以数的过来，这些居然需要上百系统来支持。
这后面存在的问题肯定让人深思，然后随着我们梳理的深入，会发现有些最主要的问题是：
- 重复建设
- 缺乏规划
这里对开发资源和物理资源的浪费将显而易见。
这些系统也成为了一个庞大的负担，我们需要花很大的精力去维护，升级，开发，同时也要花很多公司的资源去运行，监控。
那么我们在审视下，如果我们需要开发一个新的业务应用，是否能想外面创业公司一样，得到很好的服务资源呢,作为国内最强的技术公司，我们的开发实力毋庸置疑，可是我们的效率呢？
如果一个软件变得复杂难以维护需要去做代码级别的重构，那么我们这种系统级别的复杂就需要架构级别的重构了。
2.2 对开发人员技术要求很高，不利于集中精兵强将做关键系统。
作为一线互联网公司的技术开发人员，技术实力相对外部强很多，一方面原因是我们拥有很好的商业场景，需要我们用技术去保障，另一方面确实被高强度业务开发给淬炼出来的。
另外我们发现，如果我们想利用外包做一些公司内部的系统，基本只能是不可能。
当我们需要开发一个新的业务系统，
开发阶段：
开发人员就需要考虑如何设计数据库，分库分表，安全，高并发，性能，需要使用到， 数据库（mysql，Hbase），消息中间件（notify，metaq）， 缓存（Tair），分布式调用（HSF）， ...J2EE里的那些技术公司开发人员都很熟悉了。
维护阶段：
我们都知道我们队系统稳定性的要求可以说是： 稳定压倒一切。在这个大促期间，大部分开发团队的工作重心都是在围绕稳定性做准备，梳理系统架构，梳理系统强弱依赖，设计限流预案等等。
于是高并发，系统性能调优，JVM等也成为公司开发人员的强项了。
可以说，这样做几年业务系统下来，开发人员的技术能力得到很大的提升，通过呕心沥血，熬夜加班奋战来维护支持业务发展。
可是反过来想想，为什么我们做个业务系统，除了业务逻辑实现外，还需要每个开发人员掌握如此多的技能。 作为业务系统的开发人员，不是应该专注于业务逻辑的开发吗。 系统的稳定性，后端的高并发性能不是应该有更底层，更专业的团队去做吗，为什么每个开发团队都要求去做，这些不合理是由什么造成的，是分工？规划？还是技术架构？
2.3. 业务系统和平台技术系统界限不明确
公司内部经常有个这样的问题， 做技术系统的会在逐渐去做业务， 做业务系统的会想沉淀做平台， 这种现象反映大家因为KPI驱动想做出成绩，当却也是分工不明确导致大家对自己的目标不明确。
业务开发团队需要去服务业务的需求，和技术开发团队需要为业务开发提供各种能力，做好各种底层支持服务， 这种架构上的明确会带来职责上的明确。
2.4. 系统之间缺乏集成协作标准，难以协同解决业务复杂性
这一点我们需要企业中间件软件学习， 如在传统银行业务中，他们内服的各种系统可以在企业集中模式（EIP），企业总线之类的标准协同起来完成复杂的业务。
3. 我们可以做什么
软件工程很多是借鉴了建筑工程， 在建筑领域，有一个公司很引人注目，远大集团，在2010年上海世博会，他们用一天建成了远大馆而大出风头。 最近他们的一个新闻是：
远大集团19天建成57层高楼 建筑方式的革新成就中国速度”.
他们取得的成就是革新性的建筑方式，通过标准化建筑模块来建筑房屋。
如果我们能把集团多年来的技术能力积累更加标准化，模块化，让业务团队可以对这些能力快速组装使用，就是我们说期待的“中台”能力了。
技术积累已经成一个完整体系， 从云基础建设，中间件，业务基础等。 我们需要梳理我们的能力，把能力”建筑模块化“，同时能力之间通过”标准化“协同。
这样我们的开发团队可以很好的分工开发各种能力模块，同时业务系统可以标准化的使用这些模块。
3.1 构建能力超市，利用精细市场管理， 将开发模式由农贸市场转化为现代化超市模式
我们知道， 城市化发展中，超市取代农贸市场是个趋势。
原因是： 超市与农贸市场最本质的区别在于超市是连锁经营，连锁经营的特点是统一进货、统一配送和统一管理。连锁超市以连锁制为轴心，以众多的门店网络为市场依托，以中央采购制开发销售利润，以现代化的配送中心获取物流利润，将市场信息向加工制造业渗透，发展定牌商品，甚至形成供应链，开发生产利润。可以说，连锁经营是将工业生产中的标准化、程序化、规模化向流通领域延伸，在大幅度降低成本的同时也为消费者带来了看得见的实惠。
这种通过统一管理，标准化的方式可以获得规模上，效率上的最大优势。 我们的业务开发模式也应该学习现代化超市模式，用统一管理，标准化来提高效率。
目前，集团由于业务快速发展和技术规划之间的差距，如果审视我们内部的开发生态，各开发团队由各自部门业务独自发展，很多资源存在重复建设情况，技术和业务不能很好的支持互补，对彼此或对市场整体能力不清晰，这种重复造轮子就像农贸市场重复进货一样。 我们更需要现代化超市的模式，布局，库存，能力等有总体的管理和规划，各开发团队的职责和能力能清晰的管理，彼此之间能更好的协作。
能力成为这个超市的商品，不存在但是需要的能力会被采购, 没有销量的能力会逐渐废弃，销量大的能力会被增强改进， 重复的能力会被避免。能力的种类会被统一布局，能力的使用可以被监控计费
这样我们就可以形成一种有效机制，当某个能力被开发形成后，就可以在类似超市中被所有业务团队看到使用，由于业务团队对这种能力的需求，他可以被得以进一步发展来满足这些业务方需要。 而不是目前这样各业务团队需要类似的能力，下面的开发团队重复性的去开发类似功能而形成资源浪费。（比如我们想想我们内部有多少规则系统....）
能力的开发者和能力的消费者可以在能力超市的市场化规划运作下，可以形成良性高效的生态，避免资源的浪费。能力的使用者利用“超市“可以知道方便的了解内部的所有能力，能力的开发者可以响应市场的需求，开发出真正需要的能力来填补空白。
3.2 建立系统之间的类企业集成标准，让多系统之间的数据交换更加便利
传统企业中间件利用企业集成系统来协调多系统解决复杂业务问题。 公司的业务发展也需要我们的系统跟需要协调起来快速响应完成复杂业务的支持。
公司内部有很多场景需要数据之间数据同步，比如业务系统和搜索系统数据同步。 ODPS离线数据和在线数据之间数据交互等。
目前这些系统之间数据交互是通过特定系统自己定义的API或者脚本实现。 这种标准的确实，需要开发人员掌握每个系统的特定API，如果能指定一定的标准，就像企业集成一样，也将大大降低开发人员的开发门槛，提高开发的效率。
3.3 开发从J2EE时代升级到云开发时代，构建移动互联时代的快速创新能力
J2EE时代的三层架构（表现层，中间层，数据服务层）将被移动互联网云计算时代的三层架构（UI，MBaaS，平台）取代。
复杂业务系统可以在新架构基础上变得简单，松耦合，更易和内部，外部分享数据和接口。
如上图说是，目前我们的开发架构大部分还只是在第一种重度耦合的状态或部分进入SOA架构，我们需要达到第三种开发架构状态，让系统之间可以简单，规范，互通的完成复杂业务。
并且，对业务开发团队来说，他们的开发能力更专注前端，交互，需要掌握的技术栈里就只需要javascript和Restful API就够了，他们可以跟专注去理解业务模型和逻辑，快速构建业务系统，进行业务创新。
而对于后端团队，将跟专注做平台和服务，后者需要他们将J2EE时代的开发架构，比如MVC， RPC等架构向向微服务，EDA，CQRS等云时代的架构升级，更好的将系统复杂性解构，利用服务化来构建满足业务团队的需要。
在架构升级改变下，开发团队的分工也将更加明确， 比如：
业务团队-> 前端，交互，业务逻辑
后端团队-> 平台，服务，稳定性
3.4. 在集团内部建立开发者生态
让应用（业务方），开发者，平台围绕以数据形成一个良性生态，在这样一个平台，所有开发者的知识和经验可以很好的被共享，对各种业务的开发，架构的设计从设计到实现都能被大家说review，关注。同时建立开发的扩展和模块标注，让所有开发者都可以主动提交能力模块并可能被中台“能力超市”采购。
