点击上方“芋道源码”，选择“设为星标”
管她前浪，还是后浪？
能浪的浪，才是好浪！
每天 10:33 更新文章，每天掉亿点点头发...
源码精品专栏
我叫道延， 2014 年加入阿里，在阿里通信工作了近两年。2016 年年底加入业务平台团队，当时 Leader 找我的第一件事就是要解决大促的问题，第二件事就是解决安全生产的问题。
我带着这个命题进入业务平台，开始了后面的故事。今天趁这个机会，和大家分享一下关于这件事和这件事背后的一些想法，以及我对架构师的一些思考。
我对技术架构的理解
01 顶层设计
国家每 5 年有五年计划，这其实就是在国家整个层面的一个非常清晰的顶层架构设计，这里面对国民经济重大建设项目和生产力进行宏观的架构设计，本质上也是一种架构设计。在这里面，要做什么事要定义的非常清楚，要达到什么样的结果也要定义的非常清楚 。
双 11 的保障也是需要设计的。双 11 本身是一个业务的活动事件，因为规模比较大，所以需要很多的技术来支撑这个东西。技术里面我们可能要考虑低成本、高效率、高稳定，并且还要引入一些更多的新技术来支撑，也要把这些东西整合好，架构设计好，让架构可以流畅地支撑业务。
02 物理架构
我们有单元化架构，当然很多公司也有类似的架构。但是阿里的单元化架构与其他架构相比有一些本质的区别。
阿里目前单元化架构达到一个什么目标呢？通过部署异地单元将生产流量完整运行在千里之外的独立机房，从而连续性的运行业务。这几句话里面包含了非常多的关键点，一个是异地，第二个是千里之外，第三个是独立，第四个是连续性。
单元化架构的总设计师是毕玄，因为我们这块业务跟单元化的架构非常相关，所以要对它完全掌握和吃透才能往下走。
03 应用架构
目前中台里面做的比较多的叫星环，星环想达到架构的本质目的是将单纯的代码共建模式，抽象成横向和纵向的业务包模式，做到业务与业务隔离，业务与平台隔离。
这背后带来的问题是什么？我们原来产生用共建的方式支撑了 50 多个 BU 的会员、商品、交易、营销、资金、支付、库存逆向等业务，其实每个里面都是遍地开花的 if else，这就导致代码的合并也难，开发也难，测试也难，上线也难，整个过程都很痛苦。所以在 2015 年做星环的架构时，就是让这些东西不那么痛苦，慢慢的解决这些问题。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/
架构师角色
关于架构师的角色，我来说说自己的想法。
01 形散而神不散
架构其实是每个业务线都有，有些技术同学本身也是架构师的角色。阿里很早以前是专门有架构师岗位，专门的去做架构，但是做着做着架构师就做没了。因为很不接地气，它没有解决具体、真实、实际的问题。但现在，阿里的架构师岗位逐渐增加了，他们的价值在于抽象这些技术问题，解决这些问题。所以第一点是形散神不散。优秀的技术同学一直在用架构的意识，解决实际的技术和业务问题 ，这就跟普通的技术同学有本质的区别。他不光是解决这一个问题，他可能解决这一类问题，用架构的思想去解决问题。
02 前瞻性
为什么你能解决这个问题，并且能解决这一类问题？一定是需要你看的多，想的多，这背后是大量的实践和知识的积累，并且是站在过去的肩膀上。
阿里电商系统很早就建立了，我们这一代一代人在里面去做架构，都是站在前一代人的肩膀上。要去看前一代人为什么要这么设计，去想或跟他去聊，吸取他好的地方。现在可能遇到新的问题，通过其他的方法来解决一些新的问题，需要有实践和知识的积累。
接触更多的人和事，用新方法解决新问题，这个很关键。不能只看代码看一个月，要找真实的业务方，你的上游、下游、合作伙伴。比如说做双 11，我是 2016年12月到业务平台，我花了整整三个月，跟每年双 11 的大队长、重要人去聊双 11。他们是怎么理解，怎么来思考的，他们认为什么地方有问题。我再找他们要一些建议：我应该怎么去做。跟他们聊的过程中才知道我们需要做什么样的大促，要把握什么是关键点，这都是一些宝贵的财富。
03 解决复杂问题
好的架构师都在解决复杂的问题。只有复杂的问题，它才需要更多不一样的技术或更新的技术来彻底解决。高并发高可用是阿里电商面临的基本问题，但是架构师要有不一样的高并发和高稳定性的解决思路。
当前最紧急的问题，比如说用户体验、提升效率、低成本等，这些问题其实是非常复杂的。很多同学都想解决这个问题，很多种方法都在解决，但是整体来说效果不是特别明显。因为它链路太长了，链路长代表影响的业务和影响的人更多，你必须得换一种新的思路 来考虑这个问题。同时用户分层，内部的技术人员增多，这就倒逼我们去把复杂的问题简化，所以我会把解决复杂问题定义为架构师的一个典型角色。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/yudao-cloud
视频教程：https://doc.iocoder.cn/video/
架构师需要什么样的能力
架构师需要什么样的能力？我参考了外面一些同学的分享，总结出来其实就是发现问题、分析定义问题、解决问题 。
01 发现问题
对局部和全局的问题需要有发现的眼光，更应该有发现未发生问题的能力，哪些需要治标，哪些需要治本，这是发现问题的基本判断力。现在系统可能没什么大问题，但你要有发现的眼光，这些问题如果不解决，未来业务可能遇到更严重的问题。架构师看问题的眼光和别人不一样，不要只看见眼前这一个问题，还要看见这个问题背后是什么，这一类问题背后是什么，我怎么能用抽象的方法解决一类问题 。想好了以后，我就把当前的这个问题先解决掉，其他的问题用抽象的方式去解决它。
02 定义和分析问题
阿里不缺解决问题的同学，但是缺定义问题的同学。你怎么知道这是个问题，并且把这个问题定义清楚。需要将发现的问题进行抽象和归纳，定义出问题的基本要素，同时定义出问题的短期和长期方案，推进技术整体的进步。
定义问题这个要求非常高。大家平时在解决业务技术问题的时候，也需要具备分析和定义问题的能力，把一个问题定义清楚了，可以真正推动业务往前进。
解决问题需要实施路径和解决方案，协同团队和上下游，推进问题的解决 。架构要解决的问题一定不是一个局部问题，一定是一个全局问题。架构师一定会碰到各种各样的角色和链路，他要有这个能力去定义问题的解决方案和实施路径，同时要协同团队。他不能闷头做事，真的要抬头，并且要有良好的沟通能力，跟所有的同学达成共识才能往前进。
沟通能力非常关键 。你怎么把这个问题说清楚，切中问题的点，同时也能帮助上下游带来实际的效果。第二点是架构师需要能救火，但不仅仅是救眼前的火，应该救未来的火，架构师救火能力要很强。
我来阿里之前在做一个 CRM 系统。后来我要解决很多业务的问题，要把它抽象出来，去做业务问题下面的基础平台。再后来发现基础平台的问题如果要解决得更彻底，还要做下面的中间件，这样层层深入就会把整个链路打通看懂。
从 2017 年到业务平台以后，我学到了很多，包括它的系统链路是什么样的，数据链路是怎么样的，整个调用链路是怎么样的，它和底层的关系是什么样的，可能遇到什么样的问题？现在可能出现这个问题，再往后运行是不是会出现其他的问题。通过救火的过程，一次次积累对系统的了解。所以，每一次过去的积累对于解决现在的问题还都有很大的帮助，每一次问题的解决又能让自己对全局有更深的理解。
架构师的挑战
01 全局式的视角
比如看到“会员”这个业务功能，你不能仅仅看到这个功能本身，你要看到会员上面的业务是什么，谁在用会员，这叫全局。同时，会员用得最多的是导购和交易，登录仅仅是会员本身一个很小的业务功能而已。基于会员，我们有导购、有交易，把这些东西要串起来看明白，就能完整的认识到会员到底提供了什么，一定要有一个全局视角。
02 技术广度
阿里的技术特别复杂，能入职到阿里来，把阿里的整个技术栈完整摸一遍的同学真的是很了不起。以单元化架构为例，我们可能需要了解端，有 iOS、安卓、PC，还要了解 CDN、网络、接入层、服务发现、服务路由、HSF 等。数据库包括储存同步、多点写，还有消息中间件等。这些技术和产品其实平时同学们都在用，但架构师不仅在用，架构师真的是要去把玩，彻底了解透彻这些东西，这是关键点 。
给大家举个例子，像数据库组成的强同步，对我们后续技术架构演进和业务的改进都有极大的影响，这个时候大家要对数据库有一个全局的认识。
2009 年 Oracle 数据库用得非常多。我当时不是做数据库相关的，但是为了把 Oracle 数据库研究透，去学了非常多 Oracle 数据库相关的内容。了解里面的逻辑，知道它的开发态、运行态、管理态等。知识都是有延续的，后来到了阿里，可能花很短的几个小时就能把现在阿里的数据库吃透。
技术的广度非常依赖于积累 。你一定要带着问题去想，这个时候你才有记忆力，有了积累，慢慢的你技术的广度就会越来越深。你要了解数据库，你必须对下层的网络了解，所以我们要对网络、CDN 有更进一步的认识。
2009 年，我大概花了两年的时间学习网络，对交换机、路由器、骨干网、城域网，运营商怎么建网，自建的 IDC 怎么建网有了比较全面的了解，包括每天跟网络怎么交互，为什么重传高？为什么延时高，TCP/IP 第 4 层的下面 IP 第 3 层是怎么操作的，IP 下面的 MAC 层是怎么操作的，大家都要深入了解一下。
这些积累最能体现出价值的就是在救火的时候。我去救火时根本不会用现在那些平台化的工具，直接上手用 TCP 代码抓原始发文，马上能分析出很多问题。这就是平时的积累，慢慢的你就会对全局有认知。
2019 年整个核心系统上云的时候，同样跟技术的广度有关系，我们上云发生了什么变化？整个底座到云上去了，计算、存储、网络全到云上去了，那要了解云啊。在2018 年的时候，我基本把阿里云的云产品都了解了一遍，这时就会对阿里云的网络、技术有本质的了解。
架构师一定要有技术的广度。大家一定要学会积累，积累到一定程度以后，你会做到无师自通。比如你了解网络、数据库，然后你又了解了磁盘30%，当这些知识逐渐成体系了，你是有能力去消化和打通不同技术点背后的相关性，对于你的个人能力的提升和认知层面的提升有巨大的帮助。
03 持续的学习
每时每刻都在发生技术的升级和变革，只有持续不断的学习，才能对老的架构有新的认识，对于老的问题产生新的解法。要了解业界最近在发生什么变化，这个领域最关键的项目和人在做什么，学习他们的技术，学习他们的论文。我以前每天大概 2 到 3 个小时是用来学习，这几个小时的学习时间是我最放松的时间，不用去想太多事。
学习也不是说去瞎学，一定要有体系化的。首先跟你工作相关的，要体系化的去学习，从最下到最上体系化去学习，学习完了以后你会有新的不一样的认识。把你的想法可以向你的团队说出来，向你的主管说出来。
还有就是要去看论文。跟数据相关的，OLTP 和 OLAP 都有非常好的论文。看了论文以后再看其他人对论文的理解。一定要去看一些比较好的东西，跟工作相关的都可以去看，每天去学习。每天花 2 到 3 个小时去学习，三年以后你就知道自己跟别人完全不一样。有人说过：在一个行业你能付出 1 万个小时，你会跟别人形成本质的区别。但是在我们这个领域，1000 个小时就形成差别。
04 业务理解
这个一定要到实践中去，不是业务离不开架构，而是架构离不开业务，业务、架构、技术要三位一体才能达到最佳的效果。我们平时学习、实践的过程就在磨刀，但你不能说你天天在磨刀，总得要用这个刀。这就是跟业务结合起来，用不一样的思路解决实际的业务问题，会带来更低的成本、更高的效率。
最后是结果。要将技术的先进性转化为业务的先进性，忘掉屁股。这个“忘掉屁股”就是你做很多事情不是你一个人能搞定的，复杂、越大的事情是要协同更多的人。如果你就是为了你自己，比如说 KPI 去做事，我告诉你，这个事情做一次两次可以，但后面就没人跟你配合。你一定要忘掉屁股，才能慢慢的把这个事情做成，真正做到你想要的结果。
遇山开道、遇水架桥，这讲的是决心。很多时候问题确实很难解决，也需要协调更多的人。很多人可能会放弃。我们最近在做架构的升级，用国产化芯片，从底到上全链路的。如果有一方配合不到位，这事情就很难推进了。从 4 月份一直到 7 月底被阻碍了两次，第三次如果再没办法开展下去，这个事情就彻底的结束了。我们当时把整个团队召集到一起，互相打气：一定要干成。遇山开道、遇水架桥，有什么问题抛出来，大家一起来解决，要有决心，更要果断。
欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
508
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
