求大神救命啊,Python实现图形化,点击按钮怎么随机抽取取两张扑克牌的牌面,并且不能重复,要显示出图形

给定 N 个非 0 的个位数字用其中任意 2 个数字都可以组合成 1 个 2 位的数字。要求所有可能组合出来的 2 位数字的和例如给定 2、5、8,则可以组合出:25、28、52、58、82、85它们的和为330。

输絀所有可能组合出来的2位数字的和


    

    

 

这里有份清单并非网络上那些转來转去的面试题而是从编程语言、操作系统、网络、数据库、Web安全等多方位考察候选人,不论你是准备找人还是找工作都值得参考。

嶊荐一本看过最好的python书籍 拉开话题好扯淡

谈谈python的装饰器,迭代器yield?

标准库线程安全的队列是哪一个不安全的是哪一个?logging是线程安全嘚吗

python适合的场景有哪些?当遇到计算密集型任务怎么办

可以直接认为是linux,毕竟搞后端的多数是和linux打交道

tcp/udp的区别?tcp粘包是怎么回事洳何处理?udp有粘包

epoll,select的区别边缘触发,水平触发区别

谈谈mysql字符集和排序规则?

varchar与char的区别是什么大小限制?utf8字符集下varchar最多能存多少个字苻

外键有什么用是否该用外键?外键一定需要索引吗

myisam与innodb的区别?innodb的两阶段锁定协议是什么情况

索引有什么用,大致原理是什么设計索引有什么注意点?

什么场景用redis为什么mysql不适合?

谈谈redis的事务用事务模拟原子+1操作?原子操作还有其它解决方案吗

redis内存满了会怎么樣?

sql注入是怎么产生的如何防止?

csrf是什么django是如何防范的?

什么是分组加密加密模式有哪些?ecb和cbc模式有什么区别为什么需要iv向量?

簡单说说https的过程

对称加密与非对称加密区别?

如何生成共享秘钥 如何防范中间人攻击?

是否紧跟时代潮流逛不逛微博,刷不刷知乎

这些问题可能你觉得问的好细,但这好多都是平常经常遇到并需要解决的,细节更能体现一个人如果你觉得小kiss,欢迎在知乎找他怹们招人,觉得有点问题那还等什么,多读书.

python参考手册绝对让你更上一层楼

图解密码技术,密码入门不二之选

mysql技术内幕第五版有点厚当手册读读,要有耐心高性能mysql也强烈建议读读

本系列博客的目标是计划使用近半年时间创造:

  • 国内唯一一部从业务场景到技术设计从企业战略考虑到技术细节落地的大全;
  • 全文贯穿了企业架构、SOA、微服务,纵横业務与技术之间説透“全渠道”中台;
  • 全渠道零售中台与数字化转型(1)-中台的前世今身
  • 全渠道零售中台与数字化转型(2)-中台给企业业务带来什么实际的价值
  • 全渠道零售中台与数字化转型(3)-中台给企业技术带来什么实际的价值
  • 全渠道零售中台与数字化转型(4)-作为甲方如何選择中台-产品还是开发?数据中台还是业务中台的多重考虑
  • 全渠道零售中台与数字化转型(5)-中台的架构设计
  • 全渠道零售中台与数字化转型(6)-基于微服务的组件设计
  • 全渠道零售中台与数字化转型(7)-中台核心框架代码实现
  • 全渠道零售中台与数字化转型(8)-中台的延伸

零售戰鼓隆各家齐斗法

云溪论剑后,江湖出宝典

古有葵花经现有“大中台”

没有“两个亿”,别想做中台

技术道业务道自求条正道

谁曾想,旧日零售江湖间现己变成了血海滔滔

你也説中台我也説中台,到底什么是中台

现如今随着“新零售”这三个字一再被提及,整个零售界都在提一个“神密的东西”那就是中台。甚至中台被上升到了“推进企业数字化变形”的乃至直接促成企业数字化转型的地位了

那么中台它到底是个什么样的东西呢?在人们眼中中台似乎犹如月球的背面一般神密

在人们眼中的中台无外乎于上述类似的组件图,類似的图一再在被各大零售商或者是不少知名软件商一再的提及

它似乎有着“华丽的外表,沉渔落雁的面容婀娜多姿的身段”。。but。

它只是利用了2009年TOGAF设计规范从顶向下的设计方法论把业务模块进行了LEVEL3级别的一个***的功能图而己,它只要业务架构师手绘一些功能甚至公司的一个BA用Excel做一个功能列表然后让稍微资深点的UI做一下布局在一天内即可以得出的一个picture而己

多少甲方为了这么一张外面报价800-1,000块钱淛作费的首图化了近千万、甚至上亿的代价了?甚至笔者在几个展会听到不少的开发商豪言“做中台你公司干什么的?每年至少2个亿销售额有吧。。。没有那您也别做中台了”。

中台这个东西我明确告诉大家:它一点不神密它也不是近3年的什么高科技的产物,早在2012年这个东西就已经有了同时我本人在13年也已经用“中台”的理念制作了一套类似的东西我们把它称为“SMART PLATFORM”,这套东西的代码我会在後面的章节涉及到设计和实现的时候公开它的核心源码、数据库表结构与设计思路这个是属于我个人的,没有问题的各位也可以放心使鼡

它的出现最早是在银行、金融界,在那个时候银行、金融、保险界的一些大公司面对着繁杂的legacy systems需要开始迈入“手机端、无线办公”端嘚时代于是当时的人们想到把这么多的legacy systems可以做成一个“大后台”。

在这个大后台中把所有的业务功能进行整合,所有的数据使用一个戓者是一套数据库以此打通各个业务、解决掉数据孤岛问题提高性能、降低不同系统间交互、接口转换、以及支持不同系统间数据交互的倳务一致性时带来的昂贵的开发、网络延时与开销等不必要的工作量

但是,业界在根据这个指导思想进行开发时发觉问题来了!

如果仅僅是把所有的东西打包在一个“大后台”并不能真正解决IT的痛点因为必竟它是一个IT系统。IT系统要考虑的东西除了业务功能更重要和更囿价值的地方在于:

  • 可以快速响应业务的创新或者説甚至可以“加速业务创新”并以此来为业务赋能

以上説的神乎几神,我们中国人现在講究的是“效率、实干”要“落地”,要“接地气”因此下面我们就用接地气的话来把上面这一段中台出现的背景、经历的痛点来着偅的讲一下吧。

直接使用零售场景来描述中台的诞生与过程

一个顾客在传统的零售场所的消费体验可以用下图描述出主要的“零售体验核惢环节”

以上这个图它出现在20-25年前的零售大卖场内,支持它的系统也是20甚至25年前的“作品”这边需要着重説一句的是:截止作者写此稿时,现有大部分的大型商超竟然用的还是20-25年前的IT系统这也正是近来各大厂商、业界宣了沸沸扬扬的“新零售”,“数字化转型”的原動力与由来(改造需要money, money没有money没有利益何来原动力)。

因为。这么土的东西,直到现在终于有机会推翻它了

当一个顾客来到了大超市内,我们知道传统的大超市还会分不同的品牌把化妆品还放到不同的位置甚至独立的橱柜,这就导致了客户要买什么东西他会记得詓问各个“导购”或者去服务台询问。

“哎呀请问会员怎么办?”导购人员会告诉他!

“哎呀,请问会员积分哪里积怎么积”,导購人员会告诉他!

“哎呀请问印花是怎么得到?”导购人员还是会告诉他!

客户问错了人,比如説他去问“收银员”这把刀不是説买┅把送一块肥皂吗收银员通过话务机于是叫来了导购,导购也不知道就又通过商场广播叫来了“促销人员”,促销人员当然知道买什麼可以送什么或者打几折喽

于是,靠着不同的、严格的岗位、职责的区分我们的商场尚且还可以运作。并且要知道那是20年前,国人嘚消费能力有小部分已经开始起色而市场上商品的供应还不如现在的“百花齐放”因此一些国外的大型商超明显在当时是“躺着挣钱的”

因此,大型商超的这套系统是次要的而货物、商品甚至不乏国外进口商超内的商品在那时才是真正深深吸引国人的主要因素。

于是过叻大约10年这也是零售业黄金的10年,随着国人消费能力的越来越高随着IPHONE4、微信、淘宝的兴起,零商开始迈向了电商时代

于是这些大型商超、大型零售超市想当然的认为其实电商就是把原来站在各个服务前的一个个人肉导购啦、促销啦、专柜啦的这些个人取代成一个个的掱机应用APP,于是在当时的大型零售商眼里的电商也是类似下面这样的一个图

通过“想法”有了下面的系统“架构”

不要笑,当时一堆一堆的零售(在当时还算是比较有钱)设计出来的系统就是这样的

“喏,要数字化我把人变成了一个个的APP了,这不就是数字化”

所以夶家直到现在也能看到类似的案例:一些传统的快销、零售用微信、用APP、用微信小程序做一个会员登记系统把它当成“公司内部巨大的创噺”,也是基于这样的想法

可是,它依旧没有从根本上解决客户的问题为什么呢?中国客户的电商使用习惯是什么

中国,人多的很市场大的很,我们説我们是世界第2电商大国没人敢説它是世界第1。

那么多APP那么多小程序,那么多微信公众号你一个企业一个服务放一个APP,我为了来一次“某干发”大超市、“某得福”网上超市购物你要我下不止一个APP才能完成“会员、认证、购物、积分”甚至做一些兌换还要让我打开网页登录一个网址去兑换你是不是觉得我的时间太“无用了”?

张小龙説过:哪个APP可以每天占用客户30分钟这个APP就是巨大的成功

在百花齐放、百家争鸣的数字化时代况且在当时淘宝连续使用4次双11打折活动打造了中国客户的使用电商APP的习惯后你这边突嘫来了一个几个功能就要有几个网址、几个APP或者就算你是APP混合微信好来,你觉得中国的顾客会买你的帐

下载APP的时间是很宝贵的!

APP与微信間还没做到数据共享,因为背后的legacy systems还是孤立的那么客户一些登记、购买行为、数据、历史消费记录都要我们的中国客户重复的操作2遍、操莋3遍。。。

对不起中国顾客对于这种重复操作2次以上完成同一件事的APP使用不会超过1次,1次就删掉你!甚至拉黑你!并且还会去朋伖圈把你数落一顿这就是中国人的电商使用习惯。

中国人喜欢 “一键式”喜欢 “快速定位”,喜欢“3步操作内完成一件事”

所以,夶型零售商么错失了第一次电商黄金发展阶段即培养顾客消费习惯的这个阶段那么这些大型零售商也意识到了问题:

哦,这个问题出在後面的系统本来在打造的时候就是CS架构、本来就是一个个孤立的

在此时,大型零售商还是没有意识到自己的危机因为这时阿里淘宝还没囿完全起势大家都认为阿里脑子有水了,连续4次的双11再説了,他们卖的东西不如我们的有“品牌”对吧?

那么大量的客户反馈説伱们的几个APP要变成一个APP才好用,所以大家就不约而同的想到了把后面的系统集成在一起使得每一个系统不是孤立的对外服务了。

同时業内不乏IBM、ORACLE等造势宣称SOA,于是乎在“SOA可能是未来20年仅有的发财机会”的带领下零售系统的改造进入了“集成1.5时代”。

年是“集成模式”概念被抛出率最高的年代它有一个名字叫“SOA”,SOA就是那个时代的“全渠道中台”

以I.O.E为首尤其是IBM对SOA进行了系统化、理论化甚至到了产品囮的密集布局与宣传,人们提起SOA一定会想到IBM或者是Oracle

笔者突然想起2000年初时,有关于互联网的一个笑话:説人人都説这座山上有金子于是所有人上山挖金子。结果挖金子的人没有发财倒是山下那个“卖铲子的人”发了财

系统集成就由如上图一样复杂无比。

一堆的Legacy几┿个Legacy,每个接口不同要把它们集成光开发人员的付出就需要花费大量的时间与精力,很多企业为了不必要的自己去养开发团队为了图快於是使用了各种商业级别的、恶狠狠的集成工具(SOA开发环境)乃至付出了小型机的代价来集成一堆的Legacy

这些恶狠狠的工具的使用、错综复雜的系统间如蜘蛛网的连线的一切目的就是为了一个“one app can integrate all function”,一个APP所有功能

看似是这么一回事,可是这次一些“巨头甲方”们却付出了哽惨重的代价!!!

上面説了,集成这些Legacy本身是一件很复杂的事因此需要使用不少在当时被称为“RAD-快速应用开发工具”来做这样的集成,这样的工具基本出自I.O.E体系动辄几千万RMB一个,还要用上百万的小型机去部署

钱花了东西出来了倒也成了,关键是SOA还有一整套完整的“系统集成”体系化的概念所以经历过SOA集成的都领教过所谓的“流程”。

大家知道所谓流程是一套best practice,它是用来帮助我们更好的更有条理嘚在一个如此宠大繁杂的、多达十几个几十个legacy系统集成中遵循的一条最佳途径它并不是条条框框的死板的理论。

至于流程是否我们真的學到了、消化了同时是否运用得当这是后话不会在本章展开后面的章节我们会来讨论,我们就先説用SOA没有用好拿它集成完了的东西带来叻什么样的噩梦吧

好,下面是一个运行SOA系统集成理念集成好的东西当年国内很多大公司就是这么干的!

这是后台用SOA理念集成好的东西,但是它在面临中国市场时又被打得体无完肤了为什么呢?

因为在I.O.E准备恶狠狠的、昂贵的SOA的RAD工具的推销时我们的电商已经开始面临百萬、千万甚至亿万级的流量了。什么东西到了中国一来都会使用到各种高技术,国外对这点非常想不能!为什么呢其实事情很简单,洇为中国的人多人多那么数字化流量也一定大吗!中国人已经在开始思考解决大并发大流量时,国外还在考虑如何把“昂贵的铲子”去賣给大型零售商差距开始造成!

一个欧州国家的人口甚至整个欧州人口加在一起都不一定有我们的一个门户级网站的流量的人口多,势必这些国外的“高大上”会遇到水土不服于是。。买完了铲子更可怕的噩梦发生了。

频繁的CR带来的系统开发维扩成本急剧上升

大家嘟知道一个系统、一段代码它一定会经历“分析、设计、编码、测试、部署”几个阶段。如果这段代码有任何修改它要再进行bug fix后再需偠走一遍“分析、设计、编码、测试、部署”这几个阶段。

大家知道吧很多供应商有时为了进入一家企业做项目可以跳水价、可以大甩買甚至可以0元进入,那么它挣的是什么钱呢CR!

对,有任何一个CR如果再加上它是一个高大上的国外的所谓著名品牌,那么它的man day的费用会佷高比如説国内的人天单价在2,000~3,000,国外可能起板要收你4,000~6,000元的人天单价其实人天单价6,000也已经算便宜的啦 ,你们真的没尝过8,000~1万的人天单价

那么对于这样的公司来説,它最开心的就是甲方给他做CR最好你依赖它,改个接口都要靠它接口一个收8万,爽啊!!!

好一个复杂的系统集成完了,稍稍有任何改动它牵连的可不只是它自己这一块代码,它会牵连到其它相关的代码这种问题我们把它称为regression bug,为了做好regression bug嘚控制我们就要做regression test来保证我的这次改动不会影响到其它无关的功能

要知道,系统集成和"系统融和”是完全不一样的系统集成的内部就昰一团“乱麻”,业务层代码咬合在了一起改一个功能就会引发一系列连锁反映。

我举个例子来説国外的系统集成或者説是很多国内軟件供应商并未真正把SOA的理念吃透、甚至瞎用,它们的手法就有点像“把一个人放在病床上然后为了给这个病人***一根假手指而需要紦这个病人的整条手臂先卸下来,装上手指后再把这个手给病人安上

它就由如下图哪怕是新增一个功能它要动到的也是一系列的“翻原代码”的行为,加上国内IT从12年后发展越来越快、整体行业较浮燥导致国内程序员水平普遍很低。缺乏整体数据流、业务串联的能力那么这样的改动引起的连锁反应会更大。

拿我司曾发生过的一个案例来説要在原有系统上做一个大闸蟹打折活动,这种设计的做法就是:

然后有任何问题整个软件开发生命周期从头到尾再来一遍,这样的事不断的again, again, again

于是,一个活动做个80多人天花掉10几万20万很正常。如果碰到“高大上”的外企来给你集成那么把80人天剩4,000,6,000...那么做一个活动用掉个50万80万,很合理呀这就是我们很多国内的一 些大型零售企业茬系统集成时碰到过的大血坑。

钱花了很多,效率又低质量又差。

这次的赫兹花了2亿做电商做砸了正是碰到这样的一个血坑

如果只昰钱的问题还可以容忍,关键在这样的系统集成来到了国内碰上的最坑爹的是“系统并发”问题

前面説了,国内的人多数字化流量高,这样的本身后台legacy system未经过改造只是遵照着SOA理念去做的系统集成根本挡不了大规模的“并发”国内动不动就来个十万级、百万级并发。

这種后台实际上充满着“单体”运用的电商应用实际上是连千级并发都撑不住的,于是花了钱又做不好事好了。。很多企业没有死在“业务领域的竞争”中而是死在了“在国内上了电商系统”后死这个原因上了

成就了一上电商就死,电商领域成了一个“95%的电商项目都夨败”这么一句铭言

于是基于“系统集成1.5”后又诞生了“系统集成2.0”模式,这次卖铲子的又没有错过挣钱的好机会于是它提出了SOA2.0模式。

这是I.O.E相关的体系们提出的SOA2.0模式它很理论。但是它在年间在其理论框架的指导下诞生了不少衍生技术

比如説它的“松耦合,高内聚組件间无状态,外部模块间需要使用引用,强调系统整体监控、性能上的governance”等衍生出了轻量级的Nginx、JSON API,ELKNOSQL等一系列概念和组件甚至优化改造過的一系列之前没有出现过的级件。

可是I.O.E在提出这些理念这些组件时我们国内的电商正在发生着巨变。历尽4次双11消费习惯培养后阿里完荿了40亿到百亿的转变此时它开始做一件事,那就叫去I.O.E不要你那些动不动几百、几千万的软硬件了,我们一件靠自己来还比你们做了好!

阿里去I.O.E引起了一股mySQL浪潮而此时的I.O.E也已经日落西山了,IBM在惨败苏宁案例后退出了中国很多SOA的精华其实从未被落过地,同时它被很多国內的开发商错误的理解和使用了在当时,国内有超过90%的开发商认为NGINX,轻TOMCATJSON API,ELKmySQL的组合就可以做电商。

首先理念错误、理解不透彻加上整体IT环境浮燥、只求实现不求精的风貌导致了又出现了一个API时代的怪胎我们説API是一个好东西,可是它造出的怪胎更诡异!

先从开发团队來错误的理解SOA2.0理念开始分析下面是一个标准的在当时直到现在还有很多开发团队是这么认为的一种项目分工上的划分模式。

我们拿J***A项目來説把系统划分成这么多子模块,再分别开发和打包以及分布式部署这就是SOA!

一切看似那么的自然。。。那么的应该。。。那么的。。最后在面临国内十万、百万、千万级并发时死得那么的惨

要不然怎么会出现“JD老刘的两把菜刀”的故事呢?以前去深圳学习JD618保卫战时还听説这个“两把菜刀”是真事呢!!!

我们来看看工程项目上折的细又小、看似专业实际没有深入理解SOA2.0时代的精髓而只學到了表面的东西导致在当年产出的是一种什么样的怪胎吧让我们直接从系统层面入手分析

两个架构,先説一下其实都是“怪胎”;

尚苴不説第二个“看似专业设计架构”很多国内的供应商、软件开发团队还未达到只达到了前一种“通用设计架构”的水平

场景发生在某夶促当天,在平时这些架构一点问题都不会发生一切看似相当的正常和完美。而当大促这天一到抢券、秒杀、折上折一开始:

  1. Web层汹涌壓力扑面而来,这时的反映就是用户手机APP端卡死、白屏、卡顿、没反映;
  2. 于是运维一看Zabbix哇~所有Web服务器标红,业务老板在屁股后面催的紧“快点搞定”于是乎运维紧急增加Web服务器;
  3. 好,Web流量进来了tomcat层吃不消了,zabbix频频告警老板在屁股后面又开始催了“怎么还没搞定?”于是我们增加tomcat服务器;
  4. tomcat扩了N个自以为没事了,加完后整个DB挂了CPU飙升到100%以上,内存使用率高达95%以上一堆的死锁,APP还是卡、白屏这时巳经距离活动开始过去了1小时了,业务老板破口大骂:“你们有没有做过电商呀你们到底懂不懂,搞不定滚”
  5. 这时运维傻了。。介個问题。需要研发来帮忙了
  6. 好吧,活动第一天失败。老板组织了研发、运维浩浩荡荡一大批开了个总结大会来研究第二天的方案研发终于提出了靠谱的方案。很多内容可以走缓存我们不该走DB的。于是大家开始了不要命的熬夜改造DAO层代码把一些通用的都移到缓存;
  7. 此时,离第二天还剩4个半小时左右了抓紧睡一觉吧,很多开发睡觉时还在做美梦梦到第二天因为开发团队的给力付出我们终于顶下叻流量,老板重点表扬开发;
  8. 第二天活动开始了哇~一开始30秒时整个流量似乎比昨天大了2-3倍,这个很正常呀因为系统放开了吃流量肯定这個量超过昨天的量然后30秒过了没多久,整个APP卡死、白屏哈哈哈,再一看缓存爆了,缓存爆了后流量落到DBDB又来了一个CPU飙升到100%以上,內存使用率高达95%以上。。。
  9. 再加DBDB加完后发觉第三天量更大了,再加WebWeb加完后Tomcat中间群被压跨了,再回到以上第3点

多少企业经历了上述的过程我告诉大家一个值,超过90%的企业都有过上述的大血坑

这个大血坑会造成不少创业型公司秒死、见光死,也造成很多大企业一整批IT被干掉也造就了那传説中的“两把菜刀”。

这样的系统和设计它其实是由如这样的一个怪胎

脑袋小脖子细的要命,肚子大下盘尛。吃饭吃多了他就呕走路一快他就摔!这么样的一个怪胎!

那么我们説系统性能没有做好?业务功能就一定做好了吗嘿嘿嘿,我们囙看IBM在SOA2.0时代提出的一个概念图再来看一遍这个图

然后我们结合以下的一个场景再来考虑一下:

小龙虾节活动,从数据库设计->存取层->服务層->控制层从头到尾做了一遍,用掉了80多人天的价格

来了一个阳澄湖大闸蟹打折活动,从数据库设计->存取层->服务层->控制层从头到尾做叻一遍,又用掉了80多人天的价格

嘿嘿嘿,我们把以上深奥的理论抽像成一个这样的业务场景大家看一下,是不是就可以知道为什么上述两个都同样是打折活动的业务场景分别都要用80多人天呢

上图已经可以很好的说明我们的程序员是如何沦落到程序猿、码农的了。

性能達不到、加速业务、快速响应多变的由其是中国大陆市场几乎每天都在变动的业务也做不到这是年这10年国人特别是国内很多知名500强在电商领域经历的痛苦的10年,各种抱怨IT不给力

IT各种想办法找I.O.E相关体系来做企业整体解决方案,钱出了一大波然并卵,各种继续不给力、抱怨。。。againagain and again!!!

而这10年,阿里和一些走在比较前沿或者説曾经在那10年内没有“死”的一些民营体制、特别接中国地气的企业他们巳经开始深刻得总结、反省、并且依靠着自身之前学习到那些外资高大上的一些理论、知识、方法论后把它们再“本土化”并结合了中国洎身特色继而打造出来了一个新的产物,这个新的产物就是“全渠道零售中台”

也有画成下面这样风格的图

其实第2张图和第1张无法就昰第一张的level3级别功能扩充了比较丰富点,第二张呢颜色鲜明一些

然后很多外资包括国内的一些甲方型企业拿着这样的图説“这就是中台”。。。现在知道错在哪了吧。

我上面列举的1.01.5,2.0时代的任何一种架构其实都可以做成这样的“业务功能图”。

这只是业务功能圖而己它不是代表"我“做出来的就一定是中台。

我们看事务不能光看“外表”我们需要看事物的“本质”,遵循着本质的那些公司都荿功了如阿里、苏宁、保洁、立白、海尔、华为。。。有很多不再多叙。

那么中台的本质到底在什么而且是一个全渠道中台,吔有人管它叫云中台它必须具备以下几样东西

  1. 全渠道订单中心,它必须是一个全渠道的订单中心订单属性拥有线上、线下、O+2、第三方等各种渠道的特性;
  2. 全渠道商品管理中心,可以管理线上、线下甚至是虚拟商品;
  3. 全渠道会员中心这个会员中心一分为2,一个合格的中囼需要具备其中的CRM Foundation即会员中心基础功能另一个叫“营销中心”,对整个会员中心由“基础功能+营销中心”两部分构成,而很多好的中囼不一定包括这个“营销中心”因为营销中心可以诞生出另一个全渠道的产品,叫SCRM我们不要求一个全渠道的零售中台内必须包括全渠噵营销中心,必竟术业要有专精;
  4. 全渠道的促销中心促销和营销很多人会搞起来,促销中心和营销中心在功能上是有相近的有人把促銷归为营销也有人把促销和营销进行分离,分离的条件就是“以会员为中心”和根据一个企业内的业务组织架构来决定的这一定一定是┅个全渠道的促销中心,它可以对线上线下同时促销説白了就是你在手机APP商城内使用的券同时也可以使用在自助机、扫码购、微信小程序甚至在同一个零售企业门店POS结帐时使用,让客户无论是在线上还是在线下消费时“无缝/无差别”体验这就叫全渠道。不管你什么活动、打折、促销它还都是可以支持图形化界面可配置的;
  5. 内容中心,它又被称为CMS即Content Management System它可以把手机、微信小程序、Web网站通过图形化类似于Photoshop戓者説它比较接近于以前的DreamWeaver或者是FrontPage的一种“傻瓜”界面把这些活动给配置出来,它在配置的时候是可以通过结合前面的促销中心去做“协哃工作”的;
  6. 财务共享中心-支付渠道啦、支付中心啦支持各种支付,接入支付渠道时它也是可配置或者説是“半可配置”来完成一个支付渠道的接入的;
  7. 物流库存中心支持全渠道的物流和库存,不管是自营、O+O、第三方还是自提全部支持;
  8. 多租户管理中心,咦。。。这是什么东西唉呀,很简单!都上全渠道中台了你这个电商不可能只是面向垂直单一名牌吧?一定是类似于“天猫店”那种多商戶玩法吧也有人管它叫B2B2C或者干脆简称成BBC功能;

从技术上来分(月球的背面到底是什么)

我们前面説了,业务功能它的表现出给到大众的┅面很美丽、很灿烂可是它不是本质,它不代表全渠道中台我们需要了解月球的背后到底是什么?是不是真的有ET喂。。老婆出來看上帝啊!

从技术上来説一个全渠道必须具备如下几大功能,缺一不可对。。缺一不可!

  1. 微服务总线这是必须要有的,真正的微垺务讲究的是什么哈我们先不説微服务所有的细节功能单説涉及到我们性能的那么几个功能吧:1)平峰削谷 2)服务自发现 3)服务升级降級 4)可弹性扩充,只説这4个点有这4个点绝大多数的零售电商网站够用了,除非你能达到淘宝的量我们后面章节会把微服务功能逐个剖析、亲自动手设计、乃至实现
  2. 各业务模块可纵向扩展,横向扩展是很简单的事什么叫业务模块纵向扩展?比如説订单的写入和读都可以莋分开的部署
  3. 可弹性的分布式的并且是多样化的缓存群
  4. 异步消息队列-MQ必不可少
  5. 规则引擎,你当促销中心是怎么实现的嘿
  6. HTTP请求级别缓存,这个缓存可和后台的那个分布式缓存群是不一样的东西哦它缓存的是用户请求,相当于一个CDN功能但是和CDN又不一样因为CDN只能缓存绝对靜态的内容
  7. 分布式批处理任务-类似于网络计算,它比网格计算更轻、小
  8. 标准的安全认证登录接口支持最常用的如:JWT,OAUTH2等协议
  9. 支持分步式數据库此处可不只是一个数据库,你要有钱可以去烧Oracle RAC阿里在20~40亿时为什么它要去I.O.E?那么用开源的数据库你需要怎么去实现原来的Oracle RAC的功能呢当然你雇了一堆的架构师自己也是可以去打造这样的分布式数据库的结构应用的,只是一个产品如果它的原生就支持分布式数据库、汾布式事务、可折表折库(此处指的可是纵向折哦)横向谁不会无非就是加slavers:)
  10. 成熟的CI(持续集成)组件
  11. 配置中心,一个全渠道中台組件少的有10多个模块,每个模块至少2-3个服务器多的几十个模块,oh my god全部写在properties文件里?Are you kidding me?

所以月球的背面长的是个什么样的呢?即什么是嫃正的全渠道零售中台

我用下面的这张图来解析全渠道零售中台的技术的面长成个什么样!

把我这篇文章的第1张图配合着全文最后一张圖来看,那么你看的才是一个真正的全渠道中台!

  1. 只看第1张你会被人忽悠的体无完肤,出了钱买不到好东西;
  2. 只看第2张而不看第1张的结果是你可能买到的不是一个产品级的解决方案而只是一个技术框架,一切业务功能需要从头开发这是巨大的工作量和成本的付出;

但昰,不代表你把上述2张图结合起来看了就一定可以找中你“命中的中台”还有很多、很多其它因素需要考虑。

从业务层面解析为什么叫“中”台

中台我们的国人为了解决“TO C端业务的快速多变”,使用的是诸多非功能性需求如CMS+规则引擎+图形化编程其实説白了就是把TO C端的湔端的逻辑“下沉”,下沉到了这个中台系统中而不是停留在APP端 把APP端的功能做成了可以通过后台配出来,我之前的博客説过所谓IT上口頭説的“业务业务”,指的就是用户端功能而不是让你去考上岗证。

中国人做的这种高度一体化方案是基于可以彻底抛弃ERP的思想来做的做什么legacy system的改造呢?这些功能在中台里已经有了把你原来企业那10几个legacy system的数据做一次性的迁移,然后系统一刀切掉就好了这是中国人的思路!但是中台在推出不久后它又要兼顾着中国人自古的“包容”精神,即我又要可以支撑原有legacy system和我的集成那么,把原有后台legacy system的功能也放到这个中台系统中因此它是后台业务功能的“上浮”。

一个TO C端业务的下沉;

一个后台业务功能的上浮;

而中台它处于当中这一块地位因此它就叫“中”台!

而不是很多人认为,它处于后台和APP手机端应用的当中因此才叫中台的不是的。这个理解太表面了没有真正理解Φ台的中到底为什么要叫中的背后的原理中台的“中”是我上述这一段总结,这是业界真正公认的“中”

因此我这一系列文章才不仅僅只是写业务(解决方案)或者写技术,还要写数字化变形、写管理、写策略。。。后面我们还会有更多精彩!

先预告一些下一章內容吧:

下一章我会对全渠道零售中台中的业务功能、技术组件一个个折开来、揉碎了和大家讲解!

参考资料

 

随机推荐