seoshanghai net,重庆seo案例,网站空间多少钱一年,指数分布的期望和方差序章#xff1a;中台起源
游戏公司supercell 2015年马云走访supercell公司。该公司里#xff0c;10个员工就可以组成一个独立的开发团队#xff0c;称之为cell。小团队自己决定做什么样的产品#xff0c;然后推出市场#xff0c;观察市场反馈#xff1b;反馈不好的游戏中台起源
游戏公司supercell 2015年马云走访supercell公司。该公司里10个员工就可以组成一个独立的开发团队称之为cell。小团队自己决定做什么样的产品然后推出市场观察市场反馈反馈不好的游戏则会被毫不犹豫地砍掉。这样的开发模式使得Supercell公司开发的游戏大获成功而这一切成功的背后是Supercell的强大的中台的支撑。 马云访问完supercell公司后在阿里集团推行”小前台大中台“战略。 如这家公司的名字一样Supercell中每个项目团队规模都保持10人左右这种团队称之为cell细胞。每个团队其自身都能决定要开发什么样的游戏与最终是是否要面向市场发布它。而在侥幸活过原型阶段的游戏会先登陆加拿大等个别国家进行测试再基于数据表现与玩家反馈决定它是下架关服还是在验证玩法可行之后继续推向全球市场。 ——《小团队、独立性是我们开发游戏的关键》 Jim Supercell大中华区总经理 是什么支持supercell快速创新快速试错
基于“强大Super”的平台以小型“细胞cell”团队的方式推进工作 美军作战模式
前线小分队 中台炮火群美军是广义上践行”中台“理论的祖师爷 在一线战场美军通常以班为单位组织军事行动这种极小型团队行动敏捷容易捕获战机一旦发现敌情就通过指挥系统呼叫强大的炮火和空中支援给敌军以重创。美军的这种战场组织阵型与中台架构的思想是一致的战斗小组就是“小前台”强大的炮火群和空中力量是“大中台”。在强大中台的有力支撑下前端在进行业务运营和创新时会变得非常高效且灵活企业可以根据最新的市场动态展开各种尝试和调整一旦发现并验证了新的市场机遇就可以调集中台的强大能力迅速跟进抢占市场。
一 阿里业务平台BU发展史
烟囱式架构 - 中心阶段 烟囱式架构的痛点
重复建设重复造轮子人力成本浪费系统间数据难以打通业务创新时间成本高昂所有业务基建得从头搞一遍。无法快速响应市场需求
鉴于以上问题2009年阿里成立了共享事业部现在改名为业务平台BU解决这些痛点。
平台阶段 合并后的痛点 业务与业务耦合大量的if else狗皮膏药代码泛滥TP交易平台2016年支撑了50个业务 业务与平台耦合业务与平台你中有我我中有你 平台准入门槛高小业务、轻业务也要跑完所有的流程新小业务无法快速试错占领市场无法快速高效支撑新业务 细粒度的业务没有沉淀无法复用
业务架构的诞生 - 中台阶段 引入业务架构解决平台阶段的痛点BU内部诞生了如TMFGPF等业务架构框架
前台能直接触达用户的系统
中台可复用的业务系统
二 业务中台的基石业务架构
设计目标
业务与业务间隔离A业务修改不能影响B业务改一个业务回归全网业务与平台隔离 业务需求开发时无需修改平台代码而是使用平台暴露的可扩展点业务能力组件化业务流程可编排可配置
实施时的技术
业务身份微内核架构基于spi技术的扩展点Spring IOC的思想
如何做到灵活易接入的中台化产品/平台和业务隔离 仅仅达到业务代码解耦并不够商品发布系统要做一个中台化的产品。能够快速的支持新业务接入让新的业务一起共建甚至新业务的同学独立的在XPF框架上接入他们的业务是我们的目标之一。要做到高扩展快速接入新业务这里不得不提到“微内核 插件化”技术。
微内核技术 微内核是内核的一种精简形式。将通常与内核集成在一起的系统服务层被分离出来变成可以根据需求加入插件 这样就可提供更好的可扩展性和更加有效的应用环境。使用微内核设计对系统进行升级只要用新模块替换旧模块不需要改变整个操作系统。 微内核技术源于操作系统但是在互联网产品“中台化”的大浪潮之下这个技术依靠高扩展性得到了广泛的应用。 GPF微内核会暴露一系列的SPI(Service Provider Interface)接口不同的业务按需去实现这些插件接口。系统启动时程序扫描出所有实现了SPI接口的插件并集成到系统中对外提供服务。当新业务需要接入时定义好一个业务身份同时实现需要的SPI接口即可完成业务的接入同时做到业务的隔离。
如何做到业务隔离
我们给每个业务身份建立一个模型并配一个业务id。业务模型包含这个业务要用到的组件扩展点流程配置。所有业务身份构成一个业务身份列表。每个业务模型都有一个业务识别逻辑——当前用户请求是否命中该业务。用户请求进来时都会走一遍这个路由算法以确定唯一的业务身份。 业务间隔离方案
通过上述可以发现平台通用的扩展点和组件是代码复用的并没有达到之前的代码隔离要求。解决方法也简单系统初始化时每个业务身份id都会new一份通用组件和扩展点并merge自己的定制组件和扩展点。于是内存里每个业务身份id都会有一套运行时的独立且完整的组件和扩展点集合。系统真正运行的时候取到的是组件和扩展点的对象并不是代码。这样代码复用业务数据隔离。这才是最合理的方案。 业务架构的缺点
学习成本高需要弄清整个架构的机制才能上手对维护工程师要求高普通工程师无法胜任。尤其是写了多年MVC架构风格代码的工程师很难理解插件式架构的运行原理。
适用场景
如果一个系统同时支撑的业务量很少的话并不适用。没有银弹没有万能的架构每种架构都有其擅长的地方。业务场景少的情况下写if else维护成本更低。
