曾几何时，系统不断壮大，但缺口反而越补越深。
曾几何时，自诩心有韬略，但在前线却百口莫说。
曾几何时，憧憬运筹帷幄，但上线深陷焦头烂额。
有阴就有阳，IT力量的照幅越大，背后的阴影也就越大。
拜读阿里中间件首席架构师钟华老师出品的《企业IT架构转型之道》，围绕软件微服务理念，展示了阿里的研发架构转型实践，直指软件研发的核心矛盾。
读完百感交集，记录自己的感悟。
归纳书中涉足软件研发的核心矛盾，有三个。
矛盾一：指数增长的业务规模增长 vs 线性增长的需求响应能力
在互联网时代，全社会前所未有的连通，赢家通吃、强者愈强，网络在加速分化，中心节点业务指数增长。
软件业有一个隐喻：“九个人不能让一个孩子在一个月内出生”。
研发是一个复杂过程，从规划、设计到研发、运营，既是工程的力量，也有智慧的融合。
相比于传统行业非常年轻，软件行业处于范式的剧烈变革之中，尚未在体系上达成最优。
在过去软件研发受直觉主导，烟囱式开发林立，每个团队独立建造一座烟囱，建造过快会导致根基不稳。
如果无法做快，那就做少。在建筑行业这两年已经掀起了装配式建筑的革命，在工厂中生产大量的单元房屋，在现场按需组装，减少工期。
阿里从09年启动转型，探索了一条装配思维在大型互联网企业中的落地道路。
核心是从产品能力转化直接服务客户的能力，根据用户的需求来提供最适配用户需求的设计方案，降低总体成本。
需求由一系列的服务来组合，提前建设好服务，进行搭配组合，实现快速建造。
但软件相比建筑有更高的内在复杂性。
首先，如何划分服务是一大难关，服务划分太小会造成额外的资源开销，而服务划分太大，又会变成了烟囱问题的轮回。
在书中提出了演化式改进思路，根据业务的压力来滋养，不断尝试达到最佳模式。关键角色是业务架构师，类似城市规划，掌控服务边界的动态平衡。
其次，不同于建筑结构的组装，软件的组装结构无比复杂，阿里的服务暴露数量已达到20KB+，相互的组装更是天文数字。
在组装时，有 中心 和 去中心 两条道路，中心化模式会运用总线技术来联通各方，模式简洁，但当连接膨胀到一定规模后，总线本身会成为瓶颈。
去中心化是组装的首选，在消除中心总线的前提下，基于统一的技术接口标准、协议、规范进行交互，以契约先行的方式进行功能约定，达成效率和容量的平衡。
矛盾二：指数增长的人才需求 vs 线性增长的人员能力
软件业内有一句流传的话语：技术人员是最懂业务的人，因为业务逻辑都是经技术人员之手实现。
这只是技术人员的自嗨，业务部门普遍把技术部门看成支持、视为成本，觉得技术人员不懂业务。
细看来，技术人员掌握的是在具体细分领域的利基知识，而真正驱动业务发展的是全局知识。利基知识关注于解决具体问题，而全局知识关注于业务的创新和增长。
面对一项业务特征，向下走，研究规则、流程、细节，就会一步步走入利基知识；向上走，了解用途、场景、竞争对手、行业发展，则会走入全局知识。
技术人员由于工作特点，更多向下而不是向上，这也是业务部门和技术人员对“懂业务”的认识差异所在。
除了人员主动学习和探索外，书里提出了一种全新的被动学习：赋予更全局的职能，来提高技术人员的视野。
在软件人员的组成构造上，围绕“业务功能”组织团队，由项目制改为运营制。
项目是阶段性的，有终点，是短期的。运营是没有终点的，不断延续、不断累积的。
源自亚马逊的“谁构建，谁运行”的理念，采纳“一个团队在一个产品的整个生命周期中都应该保持对其拥有”的理念，一个开发团队对一个在生产环境下运行的软件负全责。
在某一个领域，投入长时间的运营之后，就自然而然的向上发展，掌握更多的全局知识，更有机会成为业务专家。
运营制同样有问题需解决。
首先，毫无疑问，项目制是一种高效配置和协调资源的方法，会带来生产力。弱化项目作用后，如何确保生产力。
这涉及到业绩考核的变革，在阿里中台研发人员的业绩跟前端的业务发展挂钩，考核包括稳定性、接入量、用户满意度三个维度，更具弹性，用业务的全局里程碑来代替项目的局部里程碑。
其次，要考虑到思维的惰性，长期身处一个领域，除了越来越丰富的业务积累外，也可能形成越来越强的思维定势。
一旦服务提供者认为服务封装的任务已经完成，当收到新的服务需求时，开发者会选择拒绝，产生新的烟囱。
阿里的实践中强调服务边界的模糊化，在服务和服务之间不设立清晰边界，不断制造新的挑战，保持选择压力，促成有生命力的服务诞生，以产品赋能团队。
矛盾三：指数增长的软件复杂性 vs 线性增长的软件稳定性
软件研发是面向增量的，而质量守护和生产运维是面向存量的，高速增长的软件复杂度会导致体系不堪重负。
分布式系统会给我们带来很大的挑战，让系统复杂度大幅增加的同时，我们还需要面对开发、测试、部署、运维等一系列的问题。
本书重新阐释了微服务的内涵：自动化运维、系统容错、智能化服务接入与傻瓜式服务编排。
作为一门工程学科，软件领域的挑战跟尺度相关，个人使用、企业使用、乃至社会使用是完全不同的挑战。
举一个最简单的场景，在分布式处理中，调试问题和单机截然不同，在庞大的集群中找到问题的发生源，需要有工具的支持和扶助。
面对分布式带来的复杂，需要平台的力量来降维。
在阿里建设了庞大的共享服务中心，从分布式数据访问、分布式消息管理、到分布式缓存、分布式事务、分布式日志等等，提供了解决方案。
这些设施沉没了大量投入，是宝贵的IT基础设施，好比生活中的水、电、宽带设施。
我曾经历过五年的敏捷转型，敏捷的根本理念在于，对于需求的快速响应和实施。越发感觉，要达到这个目标不仅仅是组织机制，人员技能的软能力体现，更重要的是有足够强的基础设施，用来降低认知负荷。
人的创造力是在技能跟挑战的平衡中产生的，而基础设施会创造一个更佳的创造环境。
相信问题早有人解决，解决的问题对后人必有价值，用技术来扭转复杂。
银弹的思考
在软件工程领域，银弹指的是单一软件工程上的突破，能够让程序开发的生产力得到一个数量级(10倍)的提升。
阿里找到了自己的银弹，但其他组织要想同样收获红利，尚需跳出技术，站在全局的视角，思考其他的隐性投入。
001
马丁·福勒的分布式设计的第一原则是：“设计分布式对象的第一个原则就是不要使用分布式对象”。
从阿里的实施历程中，分布式技术启动不难，但随之而来的是源源不断的问题和解决，曾一度成为技术黑洞。
多年分布式建设经验告诉我，在分布式方案中细节是魔鬼，逆向思维是刚需，一个小小的疏忽都可能意想不到的放大。
天下没有免费的午餐，重大收益伴随着重大成本，哪怕是拥有平台补偿也无法完全消除。
丰富的资源带来的是选择成本的上升，复杂搭配复杂，简单搭配简单，清晰自己的场景，清楚技术的定位，让技术为我所用。
微服务是一种很好的选择，但不是唯一的选择。没有一种方法可以一劳永逸的解决所有问题，适合自己的才是最好的。
002
康威在50年前提出：如果想改变一个设计架构方式，首先要改变组织结构。经常发现推动技术架构的转型和演进很难，是由于组织结构与技术架构不匹配的时候，就会相互拉扯。
从时间源头看，阿里的转型起点是共享业务事业部的设立，恰恰是组织机构调整先行。
基础设施成本高昂，大多数公司并不具备，在新IT架构转型中，势必要加入社会协作，将原先企业内部的组织问题放大成社会协作问题。
在社会协作中共识更难达成，信任体系更为松散，责任关系更为刚性。
服务消费者需要建立适应社会协作的组织结构，而服务提供者需要建立更高的自律和自我进化的动力。
003
马丁·福勒在开创“微服务”的文章结尾处很谨慎的讲到：这是一条值得走的道路，我们不能肯定地说我们将在哪里结束，但软件开发的挑战之一是，您只能基于您目前必须掌握的不完全信息做出决定。
实施IT架构转型，不仅仅是一个阶段性目标的达成，而是持续地组织适应过程。
微服务架构建设的过程，不仅是技术上的改变，也是业务不断演变的结果。
精美作品的诞生有两种方式，一种是请一位顶级设计师，而另一种是交给自然演化这位盲眼的设计师，微服务架构选择后者。
演化由自然法则来主导，在演化世界观中，整体的利益高于局部，坚持算法的驱动，相信时间的力量。
演化论世界观和企业管理中因果分明的机械论世界观有内在冲突，但自然法则不会怜悯个体，只有适者生存。
信息时代的蜂巢
书中最后提出了信息时代生态体系的建设，预言融合创兴和跨界创新将成为中国创业的主旋律，谁能将社会资源有效的整合，更好的解决社会问题，谁就将站在社会发展的风口上高飞。
预计到 2021 年，中国公有云市场规模将达到 900 亿元，这不仅是一个预言，也是巨大资源投放下，隐隐显现的未来。
《微服务设计》这本领域广受赞誉的著作，封面选择了蜂巢，蜂巢是在小个体协作下搭成的大作品，代表了自然界的装配式搭建，而微服务架构的转型无疑是希望用同样的力量撬动更大的世界。
最后留下一个思考，蜂巢有天然的规模限制，不会无限增大，是由什么因素决定的，微服务架构也有这样限制么。
网友评论