“中台”这个概念我是在2017年从公司服务端大佬那里听说的.那会整个研发团队开始重组,正式成立中台团队,在项目构架上也是由之前各个业务线各做各的改为底层通用能力由中台统一提供.我们的B端app也是在那时候改造的,在改造之前是这样的,电商业务线有自己独立的一个app,餐饮业务线、酒店业务线等等基本上每个业务线都要做一个B端app.然而saas的B端app还是有很多共通性,他们都是给商家处理订单,查看数据报表等.
比如订单管理这个模块我可以说几乎所有业务线都有这个模块,但是我们却无法将它做成通用模块.做过app的都知道app模块能不能共用主要取决与接口和UI.如果接口和UI都不一样那它们基本没有共用的可能,因为接口的出入参和UI以及交互就决定了你的逻辑.所以M层、V层、VM层都不一样所以也就谈不上共不共用了.最多就是一些工具类、基础控件、网络请求等非常基础的东西进行抽象.但是做了这些就算是app中台吗?显然不是,基础控件、工具类等只能是扩充了自己的基础库,他们一个个就像cocoapods上的一个个库一样,不带业务的.这些基础库不止是我们公司体系下的项目可以用,给其他任何一个app项目都是可以直接共用的,所以它们不能算中台,或者说中台远不止这些.
我理解的中台,它不是毫无边界的,也就是说它里面的服务是为某种划定范围的领域而抽象出来的.app中台的局限性就更高了,因为你只要稍微抽象的深一些就难免需要带UI.不同的app可能因为UI风格的不一样而导致对这个控件的要求就不一样.抽象的目的是为了让使用者不关心具体实现直接使用,但是往往因为UI的差异需要让通用控件开放出大量的UI自定义的API,加大了使用者的复杂度,让它失去抽象的意义.所以如何去规划和抽象app的通用模块似乎比服务还要麻烦些.一个模块能不能做成通用的服务取决与UI、接口、交互、逻辑,要让这些都完全一样的还真没有,也是如果这些都完全一样它们就是一个东西了.这些完全一样是不可能了,但是是否能够寻找它们其中1-2个达到一样,或者说制造、协调让它们尽可能多的一样.
做app中台它需要“天时地利人和”,用着6个字来形容再合适不过了.我们的“天时”:整个研发团队重组,服务中台化,账号体系打通、客服、消息中心等公共服务抽象,也就是说app涉及到和公共服务交互的模块,整个saas体系都是一套接口.我们的“地利”:大部分产品线重新规划,也就给这边几个app重构的可行性.我们的“人和”:在上级领导的支持下,我们和几个业务线产品达成一致,saas产品 B端app的UI风格统一,所有业务线app合并成一个app对外.这样也方便商家如果购买我们多个业务线解决方案不需要下载多个app来处理,可以在一个app内解决.而对我构架这个app来说这个UI风格统一可以解决很多不必要的麻烦.至于app是合还是分其实都可以做,对工作量的影响也就是多一个空的主工程,换换icon和启动页等.但是如果没合并成一个app对外发布我担心的是做着做着之前约定的UI风格一致就成为空话了.
为什么UI风格的统一对我们那么重要呢?
每个B端app都有登陆、修改密码、忘记密码、我的模块等,这些模块和页面不像订单管理模块那么多样化,也就是没有太多的业务玩法,再加上我们服务的账号体系打通后更是玩不出什么花来.但是他们会在UI上做花样,而UI上的花样也足够玩死你.但是有了UI风格统一之后就可以放心大胆的把账号体系做出一个通用的业务组件.像这样的业务大组件还有客服、消息、硬件设备对接等.我把这些独立的业务组件称为插件,哪个业务线需要通过配置插入到自己的业务线里面就可以直接用,业务线不需要关心具体实现.
有了“天时地利人和”后我们是如何落地和构架我们saas B端app的呢?首先十几个业务线按正常情况下应该是十几个独立app,现在要合并成一个app,如何做到迭代互不影响,又要让能共用的共用减少重复开发.单凭这点估计就有好多人觉得不可思议十几个app合并成一个app来开发,开发冲突,代码耦合、包无敌大、各业务线独立迭代会受app限制等等都会是问题.所以我们的构架要解决这些问题
1.每个业务的迭代不能相互影响,虽然发布到应用市场是一个app,但是每个业务线都是一个独立的项目有自己的git项目仓库,有自己的代码管理版本,也有自己固定的app研发.没错它平时开发起来和每个业务独立一个app是完全一样的.
2.支持敏捷开发,同一个业务线7-8项目并行开发,整个app几十个甚至上百个项目并行开发都没问题.
3.公共业务不需要重复造轮子,一次开发全部业务共享,需要的业务配置下基本就可以直接使用.
4.业务互为插件,比如一家连锁火锅店本来应该属于线下业务线,但是它可能有自己的火锅底料需要通过线上出售.线上出售火锅底料这种属于线上电商模式,而且我们已经有这样的线上业务线了,所以我们肯定不会想在线下业务线里面再做一套一样的功能.这样它需要把这个业务当作一个插件出现在他自己业务线的app里面.插件提供方定义和设计好插件API,插件使用方只要配置导入就可以使用,不需要再次开发.插件提供方会根据业务迭代同时迭代插件.插件里面的功能和本身业务线功能是一致的或者是子集,所以不需要重复开发.
5.框架统一、基类统一、性能问题、安全问题等统一设计规划,统一实现,节约成本.十几个业务线,我们ios和android2端和起来也就十几个人,按业务线平均算的话也一个业务线一个端占0.5个人.当然这样算不合理,因为这些业务线情况都不一样,无法按平均去算.应该这样去看,你就会发现成本节约在哪里了.
5.1 如果每个业务线像之前一样各做各的,一个新的app,哪怕这个app的功能再少再简单,登陆、退出、权限管理、我的、设置、意见反馈、版本管理等大大小小几十个界面基本少不了,麻雀虽小五脏俱全.这样一个新的业务线很难快速试错,时间和成本上都是问题.订单需要消息需要推送,客户需要咨询这些比较通用的服务如果也是需要重新开发那代价就非常高了.如果是按老模式开发,新开一个业务线一般一端需要2个人1-2个月的开发时间,如果按新模式一样的业务功能一个端只需要1个人半个月到1个月的开发时间,没错基本是1/4的成本.
5.2框架统一、基类统一也给节约成本提供了必要条件,每个业务线的研发应该都是相对固定的.这样对业务和代码的熟悉会让他们的开发效率提高和开发质量的保证,但是这样有一个比较严重的问题.两个业务线之间我需要救急,人员很难灵活调配.但是框架和基类的统一为这种情况提供了可行性.除了这偶尔的调配让资源更加合理利用,它还有更加重要的作用,好多基础功能减少重复劳动,合理的抽象封装让代码的可阅读性和可维护性大大提高,效率自然就上去.
6.空的主工程,可以支持每个业务线拆开打包成不同的包发布到应用市场.主工程不承载任何业务,只有包名、icon、证书、版本号、启动页、引导页这些.如果你想要分开打包,添加一个新的主工程就可以了.
先看下项目的整体构架图:
app中台整体构架图
业务组件里面我们现在有十几个业务组件,每个业务线都有一个自己的业务组件,除了业务组件之外其他都是app中台该做的事情了.构架图如果比作战略的话,那战术才是决定它成败的必要条件.所谓战术我觉得需要根据当时的实际情况和具体细节来制定施行的,细节决定成败有了更加深刻的理解.这套框架已经经过快2年的沉淀,里面有太多的点值得我去展开的,但是又必须具备一定的业务背景才能理解为什么做这样的“战术”调整.
简单举几个例子吧!
1.为了好理解这2块基础库的区别我给他们取了2个名字,XYLibs和XYPublicClasses他们是不是cocoapods私有库没啥必要联系,只是依赖技术问题.关于cocoapods有兴趣的可以看下《cocoapods原理》XYLibs就是上面说的不带业务属性的工具类等给任何公司任何app都能用的,而XYPublicClasses虽然也不带具体业务线业务,但是它是为了我们saas体系所定制的,并不是任何一个app都能直接用的.
基础库
XYLibs
XYPublicClasses
通过部分截图,也可以看出他们的区别,而且内容都不少.这里要强调的是XYLibs库最好做成多个私有库,方便其他app使用,而XYPublicClasses库因为是为我们saas系列业务定制的私有没必要拆成多个git多个私有库,相互关联也比较强.
2.关于路由和跳转机制的细节,业务组件和公共组件没有任何依赖,他们直接的交互都是通过路由来跳转.关于路由的文章网络上有很多我这边不重复,我要强调的是业务组件内部我们还有一层简易的跳转机制.基于之前的经验,一个业务线发展到一定程度哪怕是B端也是会非常复杂和庞大的.这时候我们可能会对这个业务线进行二次拆分组件.如果是从0到1的项目你想什么做都好说,但是如果是一个已有项目,你再次拆分重构影响就很大了,模块之间代码虽然用文件夹隔离但是相互跳转需要import等,总之我们拆分过一次,这种痛苦不是一两句话能说的清楚的,有兴趣可以看下《关于B端app的组件化》你可能遇到的问题当时列的也不全,因为没拆完就写了,但是可以参考下.基于之前的经验,一个业务线大的话可能还会根据具体模块来拆分,比如会员模块、订单管理等一个个都是独立的组件.这时候很多import无疑是个坑,所以我们有规定模块内部可以直接import,模块和模块之间不能直接import.而模块和模块之间的跳转没有用路由,因为我觉的太重了.所以XYJumpVC就由此而生了.
3.关于git分支管理,这么多业务线,这么多git仓库要打成一个包对外发布,如果没有把控好,没有好的流程和机制,就会出现各种冲突;各种遗漏;测试的包不是上线的包;打完包发现今天还有一个项目需要上线,代码还没合并;合并了4-5个项目发现其中一个项目今天上不了;等等不可思议的问题,而且无论出现任何一种情况对于项目组和团队都是够受的.我们按这套机制走了2年,至今没有出现以上任何问题,每周可以保存1-2个版本,每个版本可以多个项目合并发布.可以是多个业务线的多个项目,也可以是一个业务线的多个项目,发布只认项目维度,其实不太关心具体业务线了.
一个业务线只有一个项目上线情况
关于一个业务线有多个项目合并上线
4.业务互为插件设计,下面是插件使用方需要添加的配置表,它也只需要把自己想要的插件添加到配置表就可以直接用.这里面的设计思路我没打算在这里展开,我举这个例子只是为了说明项目中的每个环节都是至关重要的,只要有一个环节没做好就很可能把你项目做的乱七八糟,很难维护很难理解.不是只要一开始规划和构架好就可以放着不管,就认为一切就可以自然的按部就班的进行.像这个业务组件互为插件,在项目开始的时候根本不知道两个业务组件直接还会有关联,还会有跳转,甚至2个业务的订单消息数据还需要放到一个页面展示.
在开发的过程中业务会出现很多挑战,每个环节都是至关重要的,所以没有战术的战略形如虚设.我称这些为项目细节,把控项目细节,细节决定一切.所以想要做app中台的一定要做好准备,刚开始适当设计切勿过度设计,等具体项目情况出现再回顾到整体,该调整的就要及时的去调整.项目框架不是理论,别人的框架不一定适合你的项目,从实际出发.
就先写到这里吧!想到什么就写什么缺少统一规划,可能比较乱,大家凑合看吧!有什么好的想法欢迎留言交流!!!
网友评论