从0开始学架构00057

你好，我是华仔。

2018年，我在极客时间开设了《从0开始学架构》这门课。我和你分享了自己多年研究和实践积累得到的一套完整的架构设计方法论，来帮助你提升架构设计的能力。

为什么架构设计能力这么重要呢？因为它是技术人员晋升到高级别必备的能力，所以后来我也在QCon等场合分享了架构师怎么成长等内容。不出意外，除了架构本身的能力提升，我还被问到了很多关于职场晋升的问题。常见的典型问题有下面这些：

1. 我平时工作太忙了，没有时间专门提升自己，也不知道应该优先提升什么能力。由于平时准备就不充分，心里没底，所以就算有晋升机会，我也不敢申请，怕在大家面前丢脸，怎么办？
2. 身边跟我差不多的、甚至不如我的同事都晋升了，而我还在原地踏步。我不知道晋升这个游戏到底要怎么玩，这背后是不是有所谓的“潜规则”？
3. 我得到了领导和同事的一致认可，胸有成竹地去参加晋升答辩，却感觉像茶壶里煮饺子，有货倒不出。而且我的PPT做得像流水账或者大杂烩，讲PPT像在念课文，面对评委的问题经常大脑短路，怎么办？
4. 我信心满满地完成了晋升答辩，评委却判定我还没达到要求。我很迷茫，不知道下一个级别的具体要求是什么，怎么做才能打动评委呢？

这些问题让我回想起了自己这些年的工作经历。我在软件行业摸爬滚打了16年，先后服务过华为、UC、阿里巴巴、蚂蚁金服等公司。这些公司有个共同点，那就是都具备完善的晋升体系。

在这些公司的“打怪升级”的过程中，你们问到的这些问题，其实我也都遇到过，很多团队成员也跟我咨询、甚至吐槽过。为此，我花了很多时间去研究和思考晋升，再加上有很多实践的机会，所以我逐步积累了比较丰富的晋升经验。

这些年自己晋升、指导团队成员晋升以及担任晋升评委的经历，让我深刻地理解了为什么晋升会这么难，为什么这么多人都对晋升充满了疑问。

因为从本质上说，晋升是一个系统工程，但是却从来没有人跟你系统地介绍过它，更不用说深入地阐述它。

就算是成熟的大公司，它们虽然制定了相关规章、制度、流程，但大部分都只是晋升规则的说明，而且充斥了大量抽象和模糊的内容。这些文件对于指导员工晋升并没有太大作用，导致大部分人对晋升存在一知半解的模糊理解，甚至完全错误的理解。

为了帮助你系统和深入地理解并实践晋升，我为你准备了一门新课，《大厂晋升指南》。整个课程是一套完整的晋升方法论，涵盖了晋升这项系统工程的各个领域。

现在，课程已经上线了。我为你申请了老用户福利，一张15元专属优惠券，可与限时优惠叠加使用，到手仅需84元，建议尽早使用。

点击下方图片即可进入新课程试读，期待与你在《大厂晋升指南》里继续交流！

 

你好，我是华仔。

我们架构课的第18讲和第19讲主题是单服务器高性能模式，我们讲了PPC与TPC、Reactor与Proactor，从理论上跟你详细讲述了不同模式的实现方式和优缺点，但是并没有给出详细的测试数据对比，原因在于我自己没有整套的测试环境，也不能用公司的服务器做压力测试，因此留下了一个小小的遗憾。

幸运的是，最近我在学习的时候，无意中在网络上找到一份非常详尽的关于Linux服务器网络模型的详细系列文章。作者通过连载的方式，将iterative、forking（对应专栏的PPC模式）、preforked（对应专栏的prefork模式）、threaded（对应专栏的TPC模式）、prethreaded（对应专栏的prethread模式）、poll、epoll（对应专栏的Reactor模式）共7种模式的实现原理、实现代码、性能对比都详尽地进行了阐述，完美地弥补了专栏内容没有实际数据对比的遗憾。

因此我把核心的测试数据对比摘录出来，然后基于数据来进一步阐释，也就有了这一讲的加餐。我想第一时间分享给你，相信今天的内容可以帮助我们加深对课程里讲过的理论的理解。

下面是作者对7种模式的性能测试对比结果表格，作者在文章中并没有详细地介绍测试环境，只是简单提到了测试服务器是租来的云服务器，CPU只有1核（没有说明具体的CPU型号），对于内存、带宽、磁盘等信息并没有介绍，我们假设这些硬件相关性能都足够。从理论上来说，网络模型的核心性能部件就是CPU，因此如下数据是具备参考意义的。

这张图的数据比较多，如何去看懂这样的性能测试数据表格呢？我来分享一个有用的技巧：横向看对比，纵向看转折。

横向看对比

比如，当并发连接数是1000的时候，可以看出preforking、prethreaded、epoll三种模式性能是相近的，也意味着epoll并不是在任何场景都具备相比其它模式的性能优势。

纵向看转折

比如，prethreaded模式（作者源码中设置了100个线程）在11000并发的时候性能有2200，但12000并发连接的时候，性能急剧下降到只有970，这是什么原因呢？我推测是12000并发的时候触发了C10K问题，线程上下文切换的性能消耗超越了IO处理，成为了系统的处理瓶颈。

按照上述“横向看对比，纵向看转折”的方式，我给你分享一下我的一些解读和发现。

1. 创建进程的消耗是创建线程的消耗的4倍左右。

2. 并发2000以内时，preforked、prethreaded、epoll的性能相差无几，甚至preforked和prethreaded的性能有时候还稍微高一些。

这也是内部系统、中间件等并发数并不高的系统并不一定需要epoll的原因，用preforked和prethreaded模式能够达到相同的性能，并且实现要简单。

3. 当并发数达到8000以上，只有pthreaded和epoll模式能够继续运行，但性能也有下降，epoll的下降更加平稳一些。

4. prethreaded模式在12000并发连接的时候，性能急剧下降。

推测是触发了C10K问题，线程上下文切换的性能消耗超越了IO处理的性能消耗。

5. poll模式随着并发数增多稳定下降，因为需要遍历的描述符越多，其性能越低。

类似的还有select模式，作者没有单独写select，因为两者原理基本类似，区别是select的最大支持连接数受限于FD_SETSIZE这个参数。

6. epoll在并发数超过10000的时候性能开始下降，但下降比较平稳。

这个结论看起来比较简单，但是却隐含着一个关键的设计点：epoll不是万能的，连接数太多的时候单进程epoll也是不行的。这也是为什么Redis可以用单进程Reactor模式，而Nginx必须用多进程Reactor模式，因为Redis的应用场景是内部访问，并发数一般不会超过10000；而Nginx是互联网访问，并发数很容易超过10000。

以上是我从性能对比数据中的一些发现，这些发现能够让我们更进一步理解专栏内容中讲到的理论知识和优缺点对比，这些数据也可以指导我们在实际的架构设计中根据应用场景来选择合适的模式。

最后，我也希望你能掌握“横向看对比，纵向看转折”这个分析技巧。这个技巧在查阅和审核性能测试数据以及各种对比数据的时候，能够帮助你发现很多数据背后隐含的观点和结论。

拓展阅读与学习指南：

1. 原作者的系列文章请参考：https://unixism.net/2019/04/linux-applications-performance-introduction/

2. 原作者的测试代码GitHub仓库地址：https://github.com/shuveb/zerohttpd

3. 原作者的代码实现了一个完整的基本功能的HTTP服务器，采用的是短链接的方式，还用到了Redis来保存内容，有的代码逻辑是比较复杂的，尤其是epoll的实现部分。如果你想自己简单的只是验证网络模型的性能，可以去掉其源码中HTTP的实现部分，只是简单地返回“hello world”这样的字符串即可。

 

 

 

你好，我是华仔。

今天这期加餐，我想和你聊聊中台这个话题。

自从2015阿里巴巴提出中台概念和战略，“中台”这个技术术语逐渐火热起来，尤其是从2019年开始，各类技术大会、各类公众号都在大力宣扬中台，出版社也趁着热点赶紧出版各类中台书籍，一时间中台有“旧时王谢堂前燕，飞入寻常百姓家”的感觉。如果你跟人聊技术的时候，不发表一些中台的言论，不讨论一些中台的问题，那肯定会显得你技术有点落伍了！

如果我们仔细阅读这些文章，可能会发现一个有趣的现象，绝大部分谈中台的都是做中台的，很少看到用中台的人出来评价。从人性的角度来讲，做中台的肯定不会说中台不好，毕竟还要靠这个恰饭，王婆卖瓜不自夸的话，买瓜的人自然会少。

偶尔有几篇说中台有问题的文章，例如《中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费》《中台，我信了你的邪 | 深氪》，也很快会有人跳出来说“你们能力不行，所以中台没做好”、“中台是一个业务、组织、技术的协同，你们肯定是组织没保证”……

总而言之，现在到处都能看到做中台的人说中台如何如何好，偶尔有几个跳出来说不好的都会被质疑能力不行！

按照我的技术理念来看，没有完美的技术，没有放之四海皆好的技术，如果你只能看到一项技术的好处，而看不到坑，那实际上很可能就会掉到坑里去。

我虽然没有真正负责做过中台，但我做过平台和中间件，更为特别的是，我参与了两个基于中台的业务项目，一个项目是将手游交易系统迁移到电商中台，另一个项目是在支付中台上从0到1搭建一个钱包。这两个项目让我亲自实践了一下在阿里和蚂蚁的中台上做项目，让我有机会近距离观察中台的运作机制，在一次次与中台的讨论、PK的过程中，对中台也有了更深的理解和认识。

从我个人的经历和理解来看，目前关于中台的很多说法是言过其实、模棱两可、甚至是错误的，接下来我将给大家谈谈实际上的中台到底是怎么运作的，会有哪些坑。由于我真正就是用的阿里电商中台和蚂蚁的支付中台，因此不用质疑中台能力不行和组织能力不行才会有我说的那些问题。

中台的价值到底是什么？

关于中台的价值，你看到的是这样的（来源《一文读懂「中台」的前世今生》）：

可以让各业务部门保持相对的独立和分权，保证对业务的敏感性和创新性；另一方面，用一个强大的平台来对这些部门进行总协调和支持，平衡集权与分权，并为新业务新部门提供生长的空间，从而大幅降低组织变革的成本。中台部门提炼各业务线的共性需求，最大限度地减少“重复造轮子”。

实际上的中台是这样的。

1. 业务部门并不独立。

基于中台的业务会被分为不同优先级，大业务对于中台的影响力远远大于小业务，核心业务对中台的影响力远远大于新业务。形象点来说，中台抱大业务的大腿，小业务抱中台的大腿，因为中台也是有KPI的，中台的KPI怎么来？当然是大部分来源于支持的业务了，大业务天然会有KPI数据上的优势。

这会导致什么问题呢？大业务的创新不管是不是共性的，中台会鼎力支持，毕竟判断是不是共性需求是中台判断的，而不是每次有个新业务的时候拉上所有业务方来评估和投票；小业务就比较悲催了，中台要拒绝你，只需简单一句话“你这个业务不通用”，“你这个需求太特殊”。

如果小业务不服气能怎么办？没什么办法，不会存在仲裁委员会之类的机构，就算有，你去仲裁的时间都够你自己把业务实现5遍了！就算中台认为你的需求是共性需求，如果你是小业务，很可能也会以优先级的原因被排在很后面，这里的“很后面”可不是几天几周，很可能就是几个月半年了！而恰恰很多初创业务一开始规模肯定是比较小的，基于中台的开发模式很可能会制约创新业务的快速发展，除非这个创新业务一开始就有重量级人物挂帅，对中台能够有足够的影响力。

2. 中台并不总是能够提炼共性需求。

注意这里的需求不是指电商中台里面“交易”这个粒度的需求，而是指“交易”系统里面一个个实际的功能点，你要是坚持说“交易”是共性需求，这实际上是一句正确的废话。

事实上，提炼共性需求主要是中台从0到1的建设的时候，因为这个时候已经有多个业务需求的样本存在，哪些是共性哪些是个性是比较容易分析出来的，但一旦建成后后续的业务发展和创新，中台和业务方天然存在对共性需求的不同诉求。

业务方总是期望将自己的需求划为共性需求，因为这样就能够让中台出人来实现需求；中台总是期望先不要把需求划为共性需求，而是等到多个业务都有类似需求的时候再由中台来抽象提炼，这样才能最大化复用，否则中台每个需求都认为是共性需求的话，中台会累死。

而事实上几乎不太可能出现多个业务同时提出某个需求，除了国家颁布的法律法规相关的需求外，绝大部分业务需求都是由某个业务方先提出来的，这个时候中台是无法判断是否为共性需求的，只能又回到前面说的潜规则来操作：优先满足大业务，拒绝小业务。反正大业务的需求不管是不是共性的，做了后数据肯定好看，中台KPI有保证；小业务就算以后被证明是共性的，前期做了也没多少数据，中台很可能费力不讨好。

3. 中台的“轮子”会不断变化。

很多朋友看到“避免重复造轮子”就以为中台把轮子造好了，业务方只管用就可以了，而实际情况是中台确实把轮子造好了，但是它每隔一段时间就会把轮子换一遍，例如中台的数据模型、接口、架构等其实都是需要根据业务发展不断变化的。

为了达到中台“复用”的目标，通常情况下中台在推出新轮子后，就不会再长期维护老轮子，否则如果中台同时维护4~5个相似的轮子，复用就无从谈起。这就要求基于中台的业务都必须在某个时间段内完成轮子的切换，相当于是业务方进行了一次被动架构演进。

当然，如果没有中台，业务方的架构肯定也要随着业务的发展而演进，那这和跟随中台被动演进有什么区别呢？最主要的区别是中台的架构演进频率会比独立的业务架构演进要快，道理很简单：中台融合了多个相似业务的发展！

举个简单例子：如果中台支持10个业务，其中有1个业务发展很快，中台就必须跟着演进，剩余的9个业务即使没有任何发展，也必须跟着被动演进！更何况如果这10个业务本身都在不断发展，那中台的演进会更快！那是否存在某种牛逼的技术，让中台的演进不影响业务呢？绝大部分情况下都不可能，这是由中台演进的本质决定的：中台演进的绝大部分动力来源于业务，它的演进不可能做到反过来不影响业务。这点和技术平台（存储、消息队列这类）不一样，技术平台演进的动力来源于技术更新，是可以做到不影响业务的。

4. 中台是某类业务的中台，不是所有业务的中台。

中台的本质是提炼共性需求复用，如果业务差异太大的话，复用度不高，提炼和维护中台花费的代价抵不上中台复用带来的价值。所以，实际上应该叫“电商中台”、“支付中台”、“物流中台”、“出行中台”、“视频中台”、“保险中台”，而不应该是“阿里中台”、“腾讯中台”、“百度中台”、“滴滴中台”。

当然，因为现在“中台”概念火爆，出现了原来很多做中间件和技术平台的团队，纷纷将自己负责的“XX平台”改为“技术中台”，从广义的角度来说也可以，因为这确实是“各业务线共性需求”，毕竟存储、缓存、消息队列这些肯定是各业务线的共性需求，但通常情况下我们说中台时所指的“需求”，还是指“业务需求”，即客户可以使用到的功能。

所以，即使只是看到“茅台云商”这种中台项目的PPT，也能大概率地推断这个项目失败的可能性会非常高（图片来源：中台，我信了你的邪 | 深氪）：

中台的效果是怎样的？

关于中台的效果，你看到的是这样的（摘自《中台的问题，是技术的问题，还是人的问题》）：

因为阿里巴巴的生态非常复杂，很多业务方本身也很年轻，要怎么去做，下层到底能提供什么样的支撑是不清楚的。当有大中台思路之后，第一，我们这个体系里有什么样的能力，可以让各业务很清楚地知道，也可以让前台业务方更快的理解、选择和使用中台能力。第二、我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。

实际的中台是这样的。

1. 中台的体系有什么样的功能，业务方根本不是很清楚地知道，而是很清楚地不知道。

事实上，几乎没有人能完整地知道中台里面各个域各个子系统的能力，更加谈不上业务方更快的理解、选择和使用了。你可以随便打开一张某个技术大会上分享的中台架构，满满的一页甚至几页PPT，大框小框几十上百个，对应到具体的线上运行的系统可能几百上千个，这么复杂的一个系统，怎么可能有人知道所有的功能和细节？更何况是业务方了。

至于说中台提供完整的解决方案，业务方只要定制一下就可以快速上线，说起来容易做起来难，除非业务方是准备复制一个和已有业务基本一样的业务，否则基本上是不可能实现的。原因在于中台提供的解决方案，必然是基于已有的业务来抽象出来的“共性需求”的大集合，如果这个解决方案可定制化度很高，那么就说明可复用度比较低；如果这个解决方案的可定制化度很低，虽然可复用度高但业务可扩展度比较低。

而从中台的本质出发，中台必然会选取“可定制度低可复用度高”的方向，这就约束了只有复制一个非常类似的新业务的时候中台的解决方案才有很大价值，但是对于同一个公司来说，为何要复制两个基本一样的业务呢？如果真的有中台选择了“可定制度高”的解决方案，当新业务和已有业务有较大差异的时候，中台的解决方案并没有什么很大价值，因为大量的工作量会耗费在定制那部分。

实际上我接触的中台是这样运作的：中台会分为很多“域”，例如“交易”、“搜索”、“会员”等，然后业务方将自己的业务需求写出来，然后拉上各个域的产品接口人和技术接口人，一个域一个域的讨论。

以“会员域”为例，讨论的时候，会员域的产品接口人技术接口人肯定很熟悉会员的功能、模型和接口，业务方需要跟中台子域接口人讲解业务需求，然后中台子域接口人来评估会员当前的能力哪些是支持的，哪些是不支持的，不支持的部分是属于共性需求还是属于个性需求，如果是共性需求，需要给出中台的修改的方案，而且修改方案还要会员域的架构师进行评审，因为改中台是影响所有业务的；如果是个性需求，需要设计出中台和业务方交互的方式，例如是提供接口、配置、扩展包等。

所以如果你真正基于中台做过项目你就会发现，编码的时间确实少了，但是前期的沟通和后期的联调非常耗时间，随便做个什么项目，拉上20~30人算一般的，稍微大点的项目拉上50~100人也是很正常的。

以淘宝的中台为例，如下是淘宝电商中台共享事业部里面交易中心的结构（图片来源：《企业IT 架构转型之道》）：

注意：交易中心只是共享事业部的一个业务域，同级别的业务域从公开资料来看有10来个，而交易中心内部就有13个子功能了，这些子功能最后都可能对应1个或者多个实际运行的系统。

2. 中台的所谓的“快”，并没有严谨的衡量。

目前各类文章都会说有了中台后业务开发快，但并没有详细的案例和分析到底有多快，仅有的几个案例看起来很夸张，但没有详细背景描述其实并没有说服力。例如说某个业务新上线很快，到底是因为第一版功能很简单，还是第一个版本投入了大量的人力来做，还是真的是因为用了中台？

事实上我经历过的两个接入中台项目并不能看出来快，从实际的开发经验来看，业务方和中台的需求讲解和讨论，业务方和中台方案的设计讨论，后期的业务系统和中台系统联调这些工作量并没有减少，反而还会有一定程度的增加，因为中台在分析需求、设计方案、联调测试的时候需要考虑对其它业务的影响。

中台能够带来的效率提升主要体现在两方面：一是编码的工作量确实会少，毕竟还是有大量的代码可以重用的；二是中台的人员都对已有的类似业务和技术很熟悉，需求的确认和方案的设计会更高效，全流程综合来看，很难判断效率到底高还是低。

事实上我之前在阿里游戏做过几个从0到1的项目，因为老板重视，都是将原来类似的系统已有的核心开发人员拉过去开发新项目，最初的代码也是从原系统拷贝过去改，开发效率一样很高，核心原因简单来说就是“熟手开发”。

以上是我从基于中台的开发项目中观察到的一些问题，归纳总结出来的一些经验。总体来看好像我在质疑中台，其实不然。关于中台的好处已经有太多的文章了，这一讲试图提供从使用者的视角来看中台所看到的一些信息和问题，目的在于帮助大家更加全面地了解中台。

咱们这门“从零开始学架构”的课程提到了架构设计的三原则，第一条就是“合适原则”，这个原则对中台也是适应的。总结来说就是：中台不是灵丹妙药，不要有问题就想着用中台解决；中台也不是放之四海而皆准，明确中台的适应场景和可能的坑，才能更好地落地中台！

其实提出中台的逍遥子已经早就谆谆告诫了（来源《中台，我信了你的邪 | 深氪》）：

中台并不适用于每家公司的每个阶段。在独立业务拓展期、突破期，“一定用独立团、独立师、独立旅建制来做”，否则就会变成瓶颈；但发展到一定阶段，出现太多山头时，就要“关停并转、要合并同类项。问管理要效率，取消重复性建设”。

好了，关于中台的分享就到这里。听了今天的内容，你对中台有更多理解了吗？欢迎留言区分享你的思考，我们一起交流。

 

 

 

你好，我是华仔！

感谢你订阅我的架构专栏，架构专栏从2018年上线至今，已经有超过50000的用户订阅，相信你也已经从架构专栏中收获良多。

开设架构训练营的初衷是什么？

架构专栏以及对应的书籍《从零开始学架构》上线后，我收到了很多用户的反馈和评价，对于感谢和夸奖的部分我就不多说了，我来谈谈一个比较有意思的现象。

有一部分用户认为专栏内容是系统化的，将架构设计的本质讲清楚了，学习专栏需要一定的基础和经验，例如：

而另外一部分用户的评价截然相反，认为架构专栏和书籍是适合入门科普的，学习专栏主要是知道了一大堆架构相关的概念，例如：

也就是说，同样的内容，一部分用户认为是适合入门和科普，一部分用户却认为需要一定的架构基础才能看懂，这是怎么回事呢？

其实从我个人的写作目的来说，我的本意是将我自己多年架构设计经验和思考提炼成通用的架构方法论，剖析常见的架构模式的本质，希望通过“授人鱼不如授人渔”的方式，让你能够从本质上掌握架构设计的方法，从而能够自如地将“面向复杂度的架构设计方法论”应用到你的实际业务系统中。

那为什么会出现两种截然不同的评价和看法呢？

我认真思考了一下，其实并不是架构专栏的内容本身有问题，而是不同基础的用户对内容的理解差异导致了不同的评价和看法。

其道理和钓鱼是类似的：

• 如果我直接把鱼钓上来给你，那你肯定没法学会自己钓鱼，我不把鱼给你你就没鱼吃。
• 如果你已经有了钓鱼的一些经验，此时我把我的更好的钓鱼方法传授给你，能够纠正你的一些错误做法，解答你的一些困惑，教你一些更实用的技巧，你肯定会觉得收获很大。这就是很多用户评价架构专栏的内容很有收获的原因。
• 但是如果你从来没钓过鱼，此时我把我的钓鱼方法传授给你，你虽然知道了一大堆的钓鱼概念和方法，但是实际自己去钓鱼的时候，肯定会遇到如何将理论落到实践的问题。这就是部分用户认为架构专栏适合入门和科普的原因。

也就是说，专栏的内容是没问题的，用户的感受也是没问题的，但正如有个用户说的，“任何一本书都有其面向人群”，专栏的内容不可能涵盖架构设计的方方面面，做到面面俱到。

因此，为了满足目前还没有多少架构设计基础，但是期望提升自己架构设计能力的这部分用户，我想通过更有针对性的内容来讲解架构设计，这就是接下来我想给你介绍的“业务架构训练营”的设计初衷。

架构训练营的设计思路是什么？

你可能会有疑问：既然有了架构专栏，那么架构训练营与专栏的区别是什么？会不会只是将专栏内容搬过来而已？

关于架构训练营的思路，一开始我们就确定了一个总原则：“架构训练营不是将专栏内容改成视频形式”。我们先后讨论了几个思路，包括通过代码来训练架构能力、通过剖析开源系统来训练架构能力、通过实现单个复杂业务来训练架构能力，最终，我们确定了“面向业务的架构实战”这个思路。

简单来说，架构专栏的思路是从架构设计本身出发，给你讲述完整的架构设计方法论和常见架构模式的理论分析。当你有了一定的架构设计经验后，架构专栏能够帮助你系统地理解架构设计，将你的经验串起来形成方法论。

而架构训练营的思路是从实战出发，给你讲述如何分析业务的架构需求，如何设计合理的架构来满足业务需求，其内容除了涵盖架构专栏的核心内容外，还会增加多种业务案例来讲解具体如何结合业务来做架构。

总体上来看，架构专栏更偏理论一些，架构训练营更强调实战。

业务架构实战营可以学到什么？

训练营的第一部分，将完整介绍“面向复杂度”的架构设计方法论，目的在于帮助你系统地掌握架构领域的基础知识和技能。

具体内容涵盖架构设计相关概念、架构设计的历史和本质、架构设计原则、架构设计流程，我们可以和编程领域的知识做个类比：“面向复杂度”对应“面向对象”、“架构设计流程”对应“敏捷开发流程”、“架构设计三原则”对应“SOLID、DRY”等原则。

在训练营第二部分，主要是讲解业务架构设计套路，目的在于帮助你快速掌握架构设计技巧，做到即学即用。

具体内容涵盖高性能高可用存储、高性能高可用计算、微服务、异地多活这4种常见的架构类型，每种套路的具体内容都包括相关的成熟架构模式讲解、常见开源系统分析、以及如何选择成熟技术搭建适合业务需求的架构。

当然，你也可能会遇到没有合适的可选方案，需要自己搭建系统的情况，针对这个情况，我会给出一个实际案例，并且手把手带你从0到1，搭建一个高性能高可用的复杂系统。

训练营的第三部分内容主要是架构设计案例实战，我会通过一个完整案例来展示如何整合第一部分的基础知识技能和第二部分的架构设计套路，完成实际的业务架构设计。

为了避免你需要花费大量的精力来理解业务，我挑选了最容易理解的IM业务；同时为了演示不同业务需求导致的不同的架构需求，我设计了一个从10万用户到亿级用户的业务发展路径，分阶段讲解不同规模的业务对架构的要求，具体如何做出合理的架构设计，以及如何进行架构演进。

总体来说，架构训练营期望达到的目的是能够让你即学即用，既能够系统地掌握架构设计方法论的核心内容，又能够在实际的工作中很快地基于业务来实现合理的架构。