共计 4936 个字符，预计需要花费 13 分钟才能阅读完成。
2014 年退出阿里，在阿里通信工作了近两年。2016 年年底退出业务平台团队，过后 Leader 找我的第一件事就是要解决大促的问题，第二件事就是解决平安生产的问题。
=====================================================================================
我带着这个命题进入业务平台，开始了前面的故事。明天趁这个机会，和大家分享一下对于这件事和这件事背地的一些想法，以及我对架构师的一些思考。
我对技术架构的了解
第一点是 顶层设计 。国家每 5 年有五年计划，这其实就是在国家整个层面的一个十分清晰的顶层架构设计，这里面对国民经济重大建设项目和生产力进行宏观的架构设计，实质上也是一种架构设计。 在这外面，要做什么事要定义的十分分明，要达到什么样的后果也要定义的十分分明。
双 11 的保障也是须要设计的。双 11 自身是一个业务的流动事件，因为规模比拟大，所以须要很多的技术来撑持这个货色。技术外面咱们可能要思考低成本、高效率、高稳固，并且还要引入一些更多的新技术来撑持，也要把这些货色整合好，架构设计好，让架构能够流畅地撑持业务。
第二点是 物理架构。咱们有单元化架构，当然很多公司也有相似的架构。然而阿里的单元化架构与其余架构相比有一些实质的区别。
阿里目前单元化架构达到一个什么指标呢？通过部署异地单元将生产流量残缺运行在千里之外的独立机房，从而连续性的运行业务。这几句话外面蕴含了十分多的关键点，一个是异地，第二个是千里之外，第三个是独立，第四个是连续性。
单元化架构的总设计师是毕玄，因为咱们这块业务跟单元化的架构十分相干，所以要对它齐全把握和吃透能力往下走。
第三大点是 利用架构 ，目前中台外面做的比拟多的叫星环， 星环想达到架构的实质目标是将单纯的代码共建模式，形象成横向和纵向的业务包模式，做到业务与业务隔离，业务与平台隔离。
这背地带来的问题是什么？咱们原来产生用共建的形式撑持了 50 多个 BU 的会员、商品、交易、营销、资金、领取、库存逆向等业务，其实每个外面都是遍地开花的 if else，这就导致代码的合并也难，开发也难，测试也难，上线也难，整个过程都很苦楚。所以在 2015 年做星环的架构时，就是让这些货色不那么苦楚，缓缓的解决这些问题。
架构师角色
对于架构师的角色，我来说说本人的想法。
第一点是 形散而神不散 。 架构其实是每个业务线都有，有些技术同学自身也是架构师的角色。阿里很早以前是专门有架构师岗位，专门的去做架构，然而做着做着架构师就做没了。因为很不接地气，它没有解决具体、实在、理论的问题。但当初，阿里的架构师岗位逐步减少了，他们的价值在于形象这些技术问题，解决这些问题。所以第一点是形散神不散。优良的技术同学始终在用架构的意识，解决理论的技术和业务问题，这就跟一般的技术同学有实质的区别。他不光是解决这一个问题，他可能解决这一类问题，用架构的思维去解决问题。
第二点是前瞻性。为什么你能解决这个问题，并且能解决这一类问题？肯定是须要你看的多，想的多，这背地是大量的实际和常识的积攒，并且是站在过来的肩膀上。
阿里电商零碎很早就建设了，咱们这一代一代人在外面去做架构，都是站在前一代人的肩膀上。要去看前一代人为什么要这么设计，去想或跟他去聊，汲取他好的中央。当初可能遇到新的问题，通过其余的办法来解决一些新的问题，须要有实际和常识的积攒。
接触更多的人和事，用新办法解决新问题，这个很要害。不能只看代码看一个月，要找实在的业务方，你的上游、上游、合作伙伴。比如说做双 11，我是 2016 年 12 月到业务平台，我花了整整三个月，跟每年双 11 的大队长、重要人去聊双 11。他们是怎么了解，怎么来思考的，他们认为什么中央有问题。我再找他们要一些倡议：我应该怎么去做。跟他们聊的过程中才晓得咱们须要做什么样的大促，要把握什么是关键点，这都是一些贵重的财产。
第三点是 解决简单问题 。 好的架构师都在解决简单的问题。只有简单的问题，它才须要更多不一样的技术或更新的技术来彻底解决。高并发高可用是阿里电商面临的根本问题，然而架构师要有不一样的高并发和高稳定性的解决思路。
以后最紧急的问题，比如说用户体验、晋升效率、低成本等，这些问题其实是非常复杂的。很多同学都想解决这个问题，很多种办法都在解决，然而整体来说成果不是特地显著。因为它链路太长了，链路长代表影响的业务和影响的人更多，你必须得换一种新的思路来思考这个问题。同时用户分层，外部的技术人员增多，这就倒逼咱们去把简单的问题简化，所以我会把解决简单问题定义为架构师的一个典型角色。
架构师须要什么样的能力
架构师须要什么样的能力？我参考了里面一些同学的分享，总结进去其实就是 发现问题、剖析定义问题、解决问题。
- 发现问题
对部分和全局的问题须要有发现的眼光，更应该有发现未产生问题的能力，哪些须要治本，哪些须要治标，这是发现问题的根本判断力。当初零碎可能没什么大问题，但你要有发现的眼光，这些问题如果不解决，将来业务可能遇到更重大的问题。架构师看问题的眼光和他人不一样，不要只看见眼前这一个问题，还要看见这个问题背地是什么，这一类问题背地是什么，我怎么能用形象的办法解决一类问题。想好了当前，我就把以后的这个问题先解决掉，其余的问题用形象的形式去解决它。
- 定义和剖析问题
阿里不缺解决问题的同学，然而缺 定义问题 的同学。你怎么晓得这是个问题，并且把这个问题定义分明。须要将发现的问题进行形象和演绎，定义出问题的基本要素，同时定义出问题的短期和长期计划，推动技术整体的提高。
定义问题这个要求十分高。大家平时在解决业务技术问题的时候，也须要具备剖析和定义问题的能力，把一个问题定义分明了，能够真正推动业务往后退。
解决问题须要施行门路和解决方案，协同团队和上下游，推动问题的解决。架构要解决的问题肯定不是一个部分问题，肯定是一个全局问题。架构师肯定会碰到各种各样的角色和链路，他要有这个能力去定义问题的解决方案和施行门路，同时要协同团队。他不能闷头做事，真的要低头，并且要有良好的沟通能力，跟所有的同学达成共识能力往后退。
第一点就是 沟通能力十分要害 。你怎么把这个问题说分明，切中问题的点，同时也能帮忙上下游带来理论的成果。第二点是 架构师须要能救火，但不仅仅是救眼前的火，应该救将来的火，架构师救火能力要很强。
我来阿里之前在做一个 CRM 零碎。起初我要解决很多业务的问题，要把它形象进去，去做业务问题上面的根底平台。再起初发现根底平台的问题如果要解决得更彻底，还要做上面的中间件，这样层层深刻就会把整个链路买通看懂。
从 2017 年到业务平台当前，我学到了很多，包含它的零碎链路是什么样的，数据链路是怎么样的，整个调用链路是怎么样的，它和底层的关系是什么样的，可能遇到什么样的问题？当初可能呈现这个问题，再往后运行是不是会呈现其余的问题。通过救火的过程，一次次积攒对系统的理解。所以，每一次过来的积攒对于解决当初的问题还都有很大的帮忙，每一次问题的解决又能让本人对全局有更深的了解。
架构师的挑战
第一点是 全局式的视角。比方看到“会员”这个业务性能，你不能仅仅看到这个性能自身，你要看到会员下面的业务是什么，谁在用会员，这叫全局。同时，会员用得最多的是导购和交易，登录仅仅是会员自身一个很小的业务性能而已。基于会员，咱们有导购、有交易，把这些货色要串起来看明确，就能残缺的意识到会员到底提供了什么，肯定要有一个全局视角。
第二点是技术广度。阿里的技术特地简单，能入职到阿里来，把阿里的整个技术栈残缺摸一遍的同学真的是很了不起。以单元化架构为例，咱们可能须要理解端，有 iOS、安卓、PC，还要理解 CDN、网络、接入层、服务发现、服务路由、HSF 等。数据库包含贮存同步、多点写，还有消息中间件等。这些技术和产品其实平时同学们都在用，但架构师不仅在用，架构师真的是要去把玩，彻底理解透彻这些货色，这是关键点。
给大家举个例子，像数据库组成的强同步，对咱们后续技术架构演进和业务的改良都有极大的影响，这个时候大家要对数据库有一个全局的意识。
2009 年 Oracle 数据库用得十分多。我过后不是做数据库相干的，然而为了把 Oracle 数据库钻研透，去学了十分多 Oracle 数据库相干的内容。理解外面的逻辑，晓得它的开发态、运行态、治理态等。常识都是有连续的，起初到了阿里，可能花很短的几个小时就能把当初阿里的数据库吃透。
技术的广度十分依赖于积攒。你肯定要带着问题去想，这个时候你才有记忆力，有了积攒，缓缓的你技术的广度就会越来越深。你要理解数据库，你必须对上层的网络理解，所以咱们要对网络、CDN 有更进一步的意识。
2009 年，我大略花了两年的工夫学习网络，对交换机、路由器、骨干网、城域网，运营商怎么建网，自建的 IDC 怎么建网有了比拟全面的理解，包含每天跟网络怎么交互，为什么重传高？为什么延时高，TCP/IP 第 4 层的上面 IP 第 3 层是怎么操作的，IP 上面的 MAC 层是怎么操作的，大家都要深刻理解一下。
这些积攒最能体现出价值的就是在救火的时候。我去救火时基本不会用当初那些平台化的工具，间接上手用 TCP 代码抓原始发文，马上能剖析出很多问题。这就是平时的积攒，缓缓的你就会对全局有认知。
2019 年整个外围零碎上云的时候，同样跟技术的广度有关系，咱们上云产生了什么变动？整个底座到云下来了，计算、存储、网络全到云下来了，那要理解云啊。在 2018 年的时候，我根本把阿里云的云产品都理解了一遍，这时就会对阿里云的网络、技术有实质的理解。
架构师肯定要有技术的广度。大家肯定要学会积攒，积攒到肯定水平当前，你会做到无师自通。比方你理解网络、数据库，而后你又理解了磁盘 30%，当这些常识逐步成体系了，你是有能力去消化和买通不同技术点背地的相关性，对于你的集体能力的晋升和认知层面的晋升有微小的帮忙。
第三点是继续的学习。每时每刻都在产生技术的降级和改革，只有继续一直的学习，能力对老的架构有新的意识，对于老的问题产生新的解法。要理解业界最近在产生什么变动，这个畛域最要害的我的项目和人在做什么，学习他们的技术，学习他们的论文。我以前每天大略 2 到 3 个小时是用来学习，这几个小时的学习工夫是我最放松的工夫，不必去想太多事。
学习也不是说去瞎学，肯定要有体系化的。首先跟你工作相干的，要体系化的去学习，从最下到最上体系化去学习，学习完了当前你会有新的不一样的意识。把你的想法能够向你的团队说进去，向你的主管说进去。
还有就是要去看论文。跟数据相干的，OLTP 和 OLAP 都有十分好的论文。看了论文当前再看其他人对论文的了解。肯定要去看一些比拟好的货色，跟工作相干的都能够去看，每天去学习。每天花 2 到 3 个小时去学习，三年当前你就晓得本人跟他人齐全不一样。有人说过：在一个行业你能付出 1 万个小时，你会跟他人造成实质的区别。然而在咱们这个畛域，1000 个小时就造成差异。
第四点是业务了解。这个肯定要到实际中去，不是业务离不开架构，而是架构离不开业务，业务、架构、技术要三位一体能力达到最佳的成果。咱们平时学习、实际的过程就在磨刀，但你不能说你天天在磨刀，总得要用这个刀。这就是跟业务联合起来，用不一样的思路解决理论的业务问题，会带来更低的老本、更高的效率。
最初是后果。要将技术的先进性转化为业务的先进性，忘掉屁股。这个“忘掉屁股”就是你做很多事件不是你一个人能搞定的，简单、越大的事件是要协同更多的人。如果你就是为了你本人，比如说 KPI 去做事，我通知你，这个事件做一次两次能够，但前面就没人跟你配合。你肯定要忘掉屁股，能力缓缓的把这个事件做成，真正做到你想要的后果。
遇山开道、遇水架桥，这讲的是信心。很多时候问题的确很难解决，也须要协调更多的人。很多人可能会放弃。咱们最近在做架构的降级，用国产化芯片，从底到上全链路的。如果有一方配合不到位，这事件就很难推动了。从 4 月份始终到 7 月底被妨碍了两次，第三次如果再没方法发展上来，这个事件就彻底的完结了。咱们过后把整个团队招集到一起，相互打气：肯定要干成。遇山开道、遇水架桥，有什么问题抛出来，大家一起来解决，要有信心，更要果决。