赞
踩
中台架构这个曾经火到爆的架构模式,它成也阿里巴巴,败也阿里巴巴,也就是阿里巴巴用自己的业务去亲自践行中台架构,并取得了阶段性的成功,很多阿里巴巴的技术大咖也因此而发家,但是最终还是毁在了资本家的商业化的决策上。
就我个人理解,中台架构本身是没有错的,它可以说是少有的一种管理资源的最佳手段,也就是我们常说的集权模式。
一个企业大了,山头众多,每个山头都有一把手,各有各的小九九和利益关系,一些重大的决策到了山头之后确实很难执行,或者大打折扣且执行的效率非常的低,也许一个新来的头头,制定了一个政策,等这个头头被调走了,这些政策都还没有被执行完毕,接着又换一个新的头头,又重新来一个新官上任三把火。
那么中台架构的目的其实就是为了统一的协调这些资源,并将上面头头的决策拆分为具体的指令,并通过中台去督促和监督下面的执行部门。
其实阿里巴巴当初做中台也是出于这个目的去考虑的,并且大老板也是支持的,因此整合和重组的节奏非常快,部门和子公司执行的效率也非常的快。
的确中台架构确实给阿里巴巴那个时候的业务提效了不少,老板的决策可以说很快就得到了响应。
中台这个承上启下的部门,确实体现了它该有的价值,但是物极必反,当公司的业务部门的业务需求已经超过了中台能够提供的能力或者中台交付的速度低于底下这些业务部门业务发展的速度的时候,那么中台架构就成为了第一瓶颈(一个中台可能需要对接几十个业务部门,这个中台肯定是吃不消的)。
中台这个部门就是来提效的,因此它的规模肯定不能太大,假如你的业务团队有1000个人,那么中台的规模比业务部门小很多,比如100个人,只有这样,老板才会看到你这个部门的价值。
当中台部门成立并下沉业务之后,业务部门从1000个人降到800人,公司的业务产品依然可以快速的交付,那么中台的价值就会体现出来了。
当中台继续赋能,业务部门从800人降到500人的时候,业务产品还是可以快速的交付,老板是高兴了,但是业务部门的头头就受不了,就会集体反抗中台,毕竟自己手下的人越来越少。
如果这个时候老板提出要做更多新的产品,中台暂时不支持这些新的产品,需要重新下沉这些能力,但是又不能影响已经下沉的能力,那么光靠那100个人绝对是不能够快速交付的,于是中台就需要增加人,从100人增加到200人,甚至到500人,以及600人,那么在老板眼中这个就存在问题了,业务部分裁掉的人,又重新分担到中台部门了,这个就说不过去了,毕竟老板是看利益的,人员成本不仅没降下来,而且还增加了(中台对技术水平要求更高,因此都是花大价钱招聘过来的)。
就算是将中台扩张到600人,但是还是没办法向之前那样高效且高质量的去交付新产品,这个时候老板和背后的资本家就坐不住了,开始对中台产生质疑。
久而久之,业务部门也提出了质疑,从而演变为要将中台给拆掉,以前已经下沉的业务重新要归拢到业务部门。
其实这个本身不是中台架构的错,而是山头主义导致的权利之争,这个本来就是这个样子的。
当权利过度集中之后,一旦出现一点危机,那么这个危机就会被竞争对手无限的放大,从而导致整个中台架构的坍塌。
中台并不是没啦,而是又以小中台的形式扎根于业务部门,只是这种中台架构不再是全局性的总公司层次的管控资源,而是被削弱为子公司的层次的管控,架构模式依然在,只是权利的我范围小了很多。
https://item.jd.com/14337086.html编辑https://item.jd.com/14337086.html
“RocketMQ消息中间件实战派上下册”是我既“Spring Cloud Alibaba微服务架构实战派上下册”之后,又一本历时超过1年半的巨无霸技术实战类型的书籍。
为了提高读者阅读本书的体验性,本书总共设计了十个特色,下面我一一的给技术小伙伴阐述一下。
本书将RocketMQ的技术原理和最佳实践体系化,按照由浅到深的顺序呈现给读者,使读者可以按照章节顺序按部就班地学习。当学习完全书内容之后,读者不仅能熟悉RocketMQ的核心原理,还能充分理解RocketMQ的“根”。
本书不仅包括RocketMQ4.x(4.9.2版本)的核心原理分析和最佳实践,还包括RocketMQ5.x(5.1. 0版本)的新特性分析和最佳实践。
本书精心研究了程序类、架构类知识的认知规律,全书共分为6篇:①基础;②进阶;③高级;④高并发、高可用和高性能;⑤应用;⑥新特性,是一条相对科学的主线,让读者快速从“菜鸟”向“RocketMQ分布式架构实战高手”迈进。
一图胜于文,书中在涉及原理、架构、流程的地方配有插图,以便读者更加直观地理解。
本书创造性地分析了RocketMQ具备高并发、高可用和高性能的功能及原理,并从架构的视角展开分析,这些也是程序员进阶为技术专家或架构师必备的技能。
以下为从架构师和技术专家的视角分析RocketMQ典型案例,读者阅读完本书之后,也能够达到这样的水准。
本书介绍了大量的实战案例,能让读者“动起来”,在实践中体会功能,而不只是一种概念上的理解。
在讲解每一个知识模块时,我在思考:在这个知识模块中,哪些是读者必须实现的“标准动作”(实例);哪些“标准动作”是可以先完成的,以求读者能快速有一个感知;哪些“标准动作”具有一定难度, 需要放到后面完成。读者在实践完书中的案例之后,就能更容易理解那些抽象的概念和原理了。
本书的目标之一是,让读者在动手中学习,而不是“看书时好像全明白了,一动手却发现什么都不会”。通过体系化的理论和实战案例去培养读者的主动学习能力,这样本书的价值就会被最大化。
本书相信“知行合一”的理念,而不是“只知,而不行”,避免开发人员出现眼高手低的现象。尤其是在技术面试过程中,面试官更加看重的是既懂原理,又能够主动是实践技术的技术人。
本书以系统思维的方式,从业务功能视角剖析 RocketMQ 底层的技术原理,使读者具备快速阅读 RocketMQ 框架源码的能力。读者只有具备了这种能力,才能举一反三,实现更复杂的功能,应对更复杂的应用场景。
本书向读者展示了如何修改 RocketMQ 源码,并快速验证案例分析。这样,读者可以从中学到参与开源的技能,并为后续自己能够参与开源做准备。
为了提高读者阅读本书的体验,在有上下两册的前提下(巨无霸,超过800页),出版社不吝啬印刷成本,依然采用双色印刷。
为了提高读者学习RocketMQ的效率,我这边结合我自身从RocketMQ小白到RocketMQ专家的经历,为读者汇总了一条最佳学习路径。
RocketMQ是我深度参与研究的一款开源消息中间件,无论是从源码,还是架构场景,我都提炼了很多最佳实践。
在开源领域,技术小伙伴可以使用的开源消息中间件非常的多,比如Kafka、Pulsar等,我之所以选择研究RocketMQ,除了工作内容和角色需要之外,更多的还是自己感兴趣,因此我建议技术小伙伴一定要先培养自己的兴趣,兴趣才是提升技术硬实力的第1要素。
当然我并不止研究了RocketMQ,还研究了Pulsar和Kafka等(包括开源消息中间件生态中的主流框架),只是本书作为一本关于RocketMQ实战派的书籍,我必须要以RocketMQ为主。
假如技术小伙伴想成为Java领域的架构师或者技术专家,我强烈建议你去研究RocketMQ,它会给你带来很多意想不到的技术和架构方法论的收获,这个也是我写本书的主要目的之一。
建议技术小伙伴按照本书设计的学习路线,逐章的去阅读和实战,这样学习效果会更好。
如果技术小伙伴有技术交流的,可以通过博文视点官方的读者群找到我的联系方式,并与我沟通,我会实时的解答读者的疑问。
本文公众号“架构随笔录”
本人视频号“架构随笔录”
2021年我和博文视点合作了一本技术类型的书籍“Spring Cloud Alibaba微服务架构实战派上下册”,它是我涉足知识输出领域以来的第一本书,同时它也是我自己积累的技术池中部分技术的产出。
为了写好那本书,我几乎花费了所有的休息时间,并主动的承担了书的售后技术辅导和咨询的职责(几乎是有问必答,坚持了整整两年)。
所谓有付出总会有回报,Alibaba这本书的销量还不错,我也因此获得了博文视点颁发的2021年度优秀作者。
我很清楚,这个是博文视点为了鼓励我继续去用心写书,因此我又花了接近1年半的时间去写了RocketMQ消息中间件实战派上下册这本书。
所谓一分耕耘一份收获,我将我对RocketMQ的理解体系化的输出给喜欢技术的技术人,希望真的对大家有帮助。
2022年,我开始涉足技术直播和技术讲师领域,并和博文视点合作几次技术直播,直播效果还不错,再加上我孜孜不倦的布道“Spring Cloud Alibaba微服务架构实战派上下册”这本书相关的技术,并且这些技术都是有助于“技术人”快速成长的,因此也获得了博文视点颁发的“2023技术成长领路人”这个技术奖项,这个奖项也是为了鼓励我继续通过技术直播的方式给技术人去布道技术,因此只要我有时间,我就会孜孜不倦的去讲和聊技术。
2022年,我开始涉足企业培训和相关技术直播,并和“四维口袋”合作了几次技术直播,并荣获了2022 KVP最具价值技术专家的技术奖项。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。