mod

极客时间专栏/从0开始学架构/特别放送/加餐｜业务架构实战营开营了.md

@@ -0,0 +1,62 @@
+
+你好，我是华仔！
+
+感谢你订阅我的架构专栏，架构专栏从2018年上线至今，已经有超过50000的用户订阅，相信你也已经从架构专栏中收获良多。
+
+## 开设架构训练营的初衷是什么？
+
+架构专栏以及对应的书籍《从零开始学架构》上线后，我收到了很多用户的反馈和评价，对于感谢和夸奖的部分我就不多说了，我来谈谈一个比较有意思的现象。
+
+有一部分用户认为专栏内容是系统化的，将架构设计的本质讲清楚了，学习专栏需要一定的基础和经验，例如：<img src="https://static001.geekbang.org/resource/image/84/e5/845aa21a97dae3e8b70a564228a30ee5.png" alt=""><img src="https://static001.geekbang.org/resource/image/ac/ba/ac9585f397a91760cc7334fb27d6edba.png" alt="">
+
+而另外一部分用户的评价截然相反，认为架构专栏和书籍是适合入门科普的，学习专栏主要是知道了一大堆架构相关的概念，例如：<img src="https://static001.geekbang.org/resource/image/92/5c/92429e7abab9fe1f8e62a01baa72fd5c.png" alt=""><img src="https://static001.geekbang.org/resource/image/d3/e4/d3be19905f7be757a44yy538267b72e4.png" alt="">
+
+也就是说，同样的内容，一部分用户认为是适合入门和科普，一部分用户却认为需要一定的架构基础才能看懂，这是怎么回事呢？
+
+其实从我个人的写作目的来说，我的本意是将我自己多年架构设计经验和思考提炼成通用的架构方法论，剖析常见的架构模式的本质，希望通过“授人鱼不如授人渔”的方式，让你能够从本质上掌握架构设计的方法，从而能够自如地将“面向复杂度的架构设计方法论”应用到你的实际业务系统中。
+
+那为什么会出现两种截然不同的评价和看法呢？
+
+我认真思考了一下，其实并不是架构专栏的内容本身有问题，而是不同基础的用户对内容的理解差异导致了不同的评价和看法。
+
+其道理和钓鱼是类似的：
+
+- 如果我直接把鱼钓上来给你，那你肯定没法学会自己钓鱼，我不把鱼给你你就没鱼吃。
+- 如果你已经有了钓鱼的一些经验，此时我把我的更好的钓鱼方法传授给你，能够纠正你的一些错误做法，解答你的一些困惑，教你一些更实用的技巧，你肯定会觉得收获很大。这就是很多用户评价架构专栏的内容很有收获的原因。
+- 但是如果你从来没钓过鱼，此时我把我的钓鱼方法传授给你，你虽然知道了一大堆的钓鱼概念和方法，但是实际自己去钓鱼的时候，肯定会遇到如何将理论落到实践的问题。这就是部分用户认为架构专栏适合入门和科普的原因。
+
+也就是说，专栏的内容是没问题的，用户的感受也是没问题的，但正如有个用户说的，“任何一本书都有其面向人群”，专栏的内容不可能涵盖架构设计的方方面面，做到面面俱到。
+
+因此，为了满足目前还没有多少架构设计基础，但是期望提升自己架构设计能力的这部分用户，我想通过更有针对性的内容来讲解架构设计，这就是接下来我想给你介绍的“业务架构训练营”的设计初衷。
+
+## 架构训练营的设计思路是什么？
+
+你可能会有疑问：既然有了架构专栏，那么架构训练营与专栏的区别是什么？会不会只是将专栏内容搬过来而已？
+
+关于架构训练营的思路，一开始我们就确定了一个总原则：“架构训练营不是将专栏内容改成视频形式”。我们先后讨论了几个思路，包括通过代码来训练架构能力、通过剖析开源系统来训练架构能力、通过实现单个复杂业务来训练架构能力，最终，我们确定了“面向业务的架构实战”这个思路。
+
+简单来说，架构专栏的思路是从架构设计本身出发，给你讲述完整的架构设计方法论和常见架构模式的理论分析。当你有了一定的架构设计经验后，架构专栏能够帮助你系统地理解架构设计，将你的经验串起来形成方法论。
+
+而架构训练营的思路是从实战出发，给你讲述如何分析业务的架构需求，如何设计合理的架构来满足业务需求，其内容除了涵盖架构专栏的核心内容外，还会增加多种业务案例来讲解具体如何结合业务来做架构。
+
+总体上来看，架构专栏更偏理论一些，架构训练营更强调实战。
+
+## 业务架构实战营可以学到什么？
+
+训练营的第一部分，将完整介绍“面向复杂度”的架构设计方法论，目的在于帮助你系统地掌握架构领域的基础知识和技能。
+
+具体内容涵盖架构设计相关概念、架构设计的历史和本质、架构设计原则、架构设计流程，我们可以和编程领域的知识做个类比：“面向复杂度”对应“面向对象”、“架构设计流程”对应“敏捷开发流程”、“架构设计三原则”对应“SOLID、DRY”等原则。
+
+在训练营第二部分，主要是讲解业务架构设计套路，目的在于帮助你快速掌握架构设计技巧，做到即学即用。
+
+具体内容涵盖高性能高可用存储、高性能高可用计算、微服务、异地多活这4种常见的架构类型，每种套路的具体内容都包括相关的成熟架构模式讲解、常见开源系统分析、以及如何选择成熟技术搭建适合业务需求的架构。
+
+当然，你也可能会遇到没有合适的可选方案，需要自己搭建系统的情况，针对这个情况，我会给出一个实际案例，并且手把手带你从0到1，搭建一个高性能高可用的复杂系统。
+
+训练营的第三部分内容主要是架构设计案例实战，我会通过一个完整案例来展示如何整合第一部分的基础知识技能和第二部分的架构设计套路，完成实际的业务架构设计。
+
+为了避免你需要花费大量的精力来理解业务，我挑选了最容易理解的IM业务；同时为了演示不同业务需求导致的不同的架构需求，我设计了一个从10万用户到亿级用户的业务发展路径，分阶段讲解不同规模的业务对架构的要求，具体如何做出合理的架构设计，以及如何进行架构演进。
+
+总体来说，架构训练营期望达到的目的是能够让你即学即用，既能够系统地掌握架构设计方法论的核心内容，又能够在实际的工作中很快地基于业务来实现合理的架构。
+
+[<img src="https://static001.geekbang.org/resource/image/b0/bf/b0afc0bff438427044d6349ab88c9ebf.jpg" alt="">](https://u.geekbang.org/subject/arch2nd?utm_source=u_nav_web&amp;utm_medium=u_nav_web&amp;utm_term=u_nav_web)

极客时间专栏/从0开始学架构/特别放送/加餐｜单服务器高性能模式性能对比.md

@@ -0,0 +1,76 @@
+
+你好，我是华仔。
+
+我们架构课的[第18讲](https://time.geekbang.org/column/article/8697)和[第19讲](https://time.geekbang.org/column/article/8805)主题是单服务器高性能模式，我们讲了PPC与TPC、Reactor与Proactor，从理论上跟你详细讲述了不同模式的实现方式和优缺点，但是并没有给出详细的测试数据对比，原因在于我自己没有整套的测试环境，也不能用公司的服务器做压力测试，因此留下了一个小小的遗憾。
+
+幸运的是，最近我在学习的时候，无意中在网络上找到一份非常详尽的关于Linux服务器网络模型的详细系列文章。作者通过连载的方式，将iterative、forking（对应专栏的PPC模式）、preforked（对应专栏的prefork模式）、threaded（对应专栏的TPC模式）、prethreaded（对应专栏的prethread模式）、poll、epoll（对应专栏的Reactor模式）共7种模式的实现原理、实现代码、性能对比都详尽地进行了阐述，完美地弥补了专栏内容没有实际数据对比的遗憾。
+
+因此我把核心的测试数据对比摘录出来，然后基于数据来进一步阐释，也就有了这一讲的加餐。我想第一时间分享给你，相信今天的内容可以帮助我们加深对课程里讲过的理论的理解。
+
+下面是作者对7种模式的性能测试对比结果表格，作者在文章中并没有详细地介绍测试环境，只是简单提到了测试服务器是租来的云服务器，**CPU只有1核**（没有说明具体的CPU型号），对于内存、带宽、磁盘等信息并没有介绍，我们假设这些硬件相关性能都足够。从理论上来说，网络模型的核心性能部件就是CPU，因此如下数据是具备参考意义的。
+
+<img src="https://static001.geekbang.org/resource/image/21/e5/2121684ed5723579a817d6a47d259be5.png" alt="">
+
+这张图的数据比较多，如何去看懂这样的性能测试数据表格呢？我来分享一个有用的技巧：**横向看对比，纵向看转折**。
+
+### 横向看对比
+
+比如，当并发连接数是1000的时候，可以看出preforking、prethreaded、epoll三种模式性能是相近的，也意味着epoll并不是在任何场景都具备相比其它模式的性能优势。
+
+<img src="https://static001.geekbang.org/resource/image/7a/98/7a85c2a05e828ca5bfb2ba98d9e0cd98.png" alt="">
+
+### 纵向看转折
+
+比如，prethreaded模式（作者源码中设置了100个线程）在11000并发的时候性能有2200，但12000并发连接的时候，性能急剧下降到只有970，这是什么原因呢？我推测是12000并发的时候触发了C10K问题，线程上下文切换的性能消耗超越了IO处理，成为了系统的处理瓶颈。
+
+<img src="https://static001.geekbang.org/resource/image/3a/08/3acb8af02e70c68bfa00e900c0d0fe08.png" alt="">
+
+按照上述“横向看对比，纵向看转折”的方式，我给你分享一下我的一些解读和发现。
+
+1. 创建进程的消耗是创建线程的消耗的4倍左右。
+
+<img src="https://static001.geekbang.org/resource/image/5e/0f/5ecb69f4867c1493b78d837163f4a90f.png" alt="">
+
+1. 并发2000以内时，preforked、prethreaded、epoll的性能相差无几，甚至preforked和prethreaded的性能有时候还稍微高一些。
+
+<img src="https://static001.geekbang.org/resource/image/af/ea/af8f0f78c2d9cb181a23eea955e7a8ea.png" alt="">
+
+这也是内部系统、中间件等并发数并不高的系统并不一定需要epoll的原因，用preforked和prethreaded模式能够达到相同的性能，并且实现要简单。
+
+1. 当并发数达到8000以上，只有pthreaded和epoll模式能够继续运行，但性能也有下降，epoll的下降更加平稳一些。
+
+<img src="https://static001.geekbang.org/resource/image/94/bc/9420050d285f4058b2bd315cdd395cbc.png" alt="">
+
+1. prethreaded模式在12000并发连接的时候，性能急剧下降。
+
+<img src="https://static001.geekbang.org/resource/image/3a/08/3acb8af02e70c68bfa00e900c0d0fe08.png" alt="">
+
+推测是触发了C10K问题，线程上下文切换的性能消耗超越了IO处理的性能消耗。
+
+1. poll模式随着并发数增多稳定下降，因为需要遍历的描述符越多，其性能越低。
+
+<img src="https://static001.geekbang.org/resource/image/d6/52/d64477859d784686895ac91c5224d852.png" alt="">
+
+类似的还有select模式，作者没有单独写select，因为两者原理基本类似，区别是select的最大支持连接数受限于FD_SETSIZE这个参数。
+
+1. epoll在并发数超过10000的时候性能开始下降，但下降比较平稳。
+
+<img src="https://static001.geekbang.org/resource/image/5b/d2/5b32b9d7b31df5a6067deca3ccc0f2d2.png" alt="">
+
+这个结论看起来比较简单，但是却隐含着一个关键的设计点：**epoll不是万能的，连接数太多的时候单进程epoll也是不行的**。这也是为什么Redis可以用单进程Reactor模式，而Nginx必须用多进程Reactor模式，因为Redis的应用场景是内部访问，并发数一般不会超过10000；而Nginx是互联网访问，并发数很容易超过10000。
+
+以上是我从性能对比数据中的一些发现，这些发现能够让我们更进一步理解专栏内容中讲到的理论知识和优缺点对比，这些数据也可以指导我们在实际的架构设计中根据应用场景来选择合适的模式。
+
+最后，我也希望你能掌握“**横向看对比，纵向看转折**”这个分析技巧。这个技巧在查阅和审核性能测试数据以及各种对比数据的时候，能够帮助你发现很多数据背后隐含的观点和结论。
+
+拓展阅读与学习指南：
+
+<li>
+原作者的系列文章请参考：[https://unixism.net/2019/04/linux-applications-performance-introduction/](https://unixism.net/2019/04/linux-applications-performance-introduction/)
+</li>
+<li>
+原作者的测试代码GitHub仓库地址：[https://github.com/shuveb/zerohttpd](https://github.com/shuveb/zerohttpd)
+</li>
+<li>
+原作者的代码实现了一个完整的基本功能的HTTP服务器，采用的是短链接的方式，还用到了Redis来保存内容，有的代码逻辑是比较复杂的，尤其是epoll的实现部分。如果你想自己简单的只是验证网络模型的性能，可以去掉其源码中HTTP的实现部分，只是简单地返回“hello world”这样的字符串即可。
+</li>

极客时间专栏/从0开始学架构/特别放送/加餐｜扒一扒中台皇帝的外衣.md

@@ -0,0 +1,115 @@
+<audio id="audio" title="加餐｜扒一扒中台皇帝的外衣" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a9/16/a976698ec16a72f3da91939f23d49f16.mp3"></audio>
+
+你好，我是华仔。
+
+今天这期加餐，我想和你聊聊中台这个话题。
+
+自从2015阿里巴巴提出中台概念和战略，“中台”这个技术术语逐渐火热起来，尤其是从2019年开始，各类技术大会、各类公众号都在大力宣扬中台，出版社也趁着热点赶紧出版各类中台书籍，一时间中台有“旧时王谢堂前燕，飞入寻常百姓家”的感觉。如果你跟人聊技术的时候，不发表一些中台的言论，不讨论一些中台的问题，那肯定会显得你技术有点落伍了！
+
+如果我们仔细阅读这些文章，可能会发现一个有趣的现象，绝大部分谈中台的都是做中台的，很少看到用中台的人出来评价。从人性的角度来讲，做中台的肯定不会说中台不好，毕竟还要靠这个恰饭，王婆卖瓜不自夸的话，买瓜的人自然会少。
+
+偶尔有几篇说中台有问题的文章，例如《[中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费](https://mp.weixin.qq.com/s/yfhaEkO1DG_ihJMhwtkWjA)》《[中台，我信了你的邪 | 深氪](https://mp.weixin.qq.com/s/9j3BnR3UqA-lnJDoM5Hrvg)》，也很快会有人跳出来说“你们能力不行，所以中台没做好”、“中台是一个业务、组织、技术的协同，你们肯定是组织没保证”……
+
+总而言之，现在到处都能看到做中台的人说中台如何如何好，偶尔有几个跳出来说不好的都会被质疑能力不行！
+
+按照我的技术理念来看，没有完美的技术，没有放之四海皆好的技术，如果你只能看到一项技术的好处，而看不到坑，那实际上很可能就会掉到坑里去。
+
+我虽然没有真正负责做过中台，但我做过平台和中间件，更为特别的是，我参与了两个基于中台的业务项目，一个项目是将手游交易系统迁移到电商中台，另一个项目是在支付中台上从0到1搭建一个钱包。这两个项目让我亲自实践了一下在阿里和蚂蚁的中台上做项目，让我有机会近距离观察中台的运作机制，在一次次与中台的讨论、PK的过程中，对中台也有了更深的理解和认识。
+
+从我个人的经历和理解来看，目前关于中台的很多说法是言过其实、模棱两可、甚至是错误的，接下来我将给大家谈谈实际上的中台到底是怎么运作的，会有哪些坑。由于我真正就是用的阿里电商中台和蚂蚁的支付中台，因此不用质疑中台能力不行和组织能力不行才会有我说的那些问题。
+
+## 中台的价值到底是什么？
+
+关于中台的价值，你看到的是这样的（来源《[一文读懂「中台」的前世今生](https://mp.weixin.qq.com/s/ZdNEgn1gxyat9PeOeycHTg)》）：
+
+可以让各业务部门保持相对的独立和分权，保证对业务的敏感性和创新性；另一方面，用一个强大的平台来对这些部门进行总协调和支持，平衡集权与分权，并为新业务新部门提供生长的空间，从而大幅降低组织变革的成本。**中台部门提炼各业务线的共性需求，最大限度地减少“重复造轮子”。**
+
+实际上的中台是这样的。
+
+**1.  业务部门并不独立。**
+
+基于中台的业务会被分为不同优先级，大业务对于中台的影响力远远大于小业务，核心业务对中台的影响力远远大于新业务。形象点来说，中台抱大业务的大腿，小业务抱中台的大腿，因为中台也是有KPI的，中台的KPI怎么来？当然是大部分来源于支持的业务了，大业务天然会有KPI数据上的优势。
+
+这会导致什么问题呢？大业务的创新不管是不是共性的，中台会鼎力支持，毕竟判断是不是共性需求是中台判断的，而不是每次有个新业务的时候拉上所有业务方来评估和投票；小业务就比较悲催了，中台要拒绝你，只需简单一句话“你这个业务不通用”，“你这个需求太特殊”。
+
+如果小业务不服气能怎么办？没什么办法，不会存在仲裁委员会之类的机构，就算有，你去仲裁的时间都够你自己把业务实现5遍了！就算中台认为你的需求是共性需求，如果你是小业务，很可能也会以优先级的原因被排在很后面，这里的“很后面”可不是几天几周，很可能就是几个月半年了！而恰恰很多初创业务一开始规模肯定是比较小的，基于中台的开发模式很可能会制约创新业务的快速发展，除非这个创新业务一开始就有重量级人物挂帅，对中台能够有足够的影响力。
+
+**2.  中台并不总是能够提炼共性需求。**
+
+注意这里的需求不是指电商中台里面“交易”这个粒度的需求，而是指“交易”系统里面一个个实际的功能点，你要是坚持说“交易”是共性需求，这实际上是一句正确的废话。
+
+事实上，提炼共性需求主要是中台从0到1的建设的时候，因为这个时候已经有多个业务需求的样本存在，哪些是共性哪些是个性是比较容易分析出来的，但一旦建成后后续的业务发展和创新，中台和业务方天然存在对共性需求的不同诉求。
+
+业务方总是期望将自己的需求划为共性需求，因为这样就能够让中台出人来实现需求；中台总是期望先不要把需求划为共性需求，而是等到多个业务都有类似需求的时候再由中台来抽象提炼，这样才能最大化复用，否则中台每个需求都认为是共性需求的话，中台会累死。
+
+而事实上几乎不太可能出现多个业务同时提出某个需求，除了国家颁布的法律法规相关的需求外，绝大部分业务需求都是由某个业务方先提出来的，这个时候中台是无法判断是否为共性需求的，只能又回到前面说的潜规则来操作：优先满足大业务，拒绝小业务。反正大业务的需求不管是不是共性的，做了后数据肯定好看，中台KPI有保证；小业务就算以后被证明是共性的，前期做了也没多少数据，中台很可能费力不讨好。
+
+**3.  中台的“轮子”会不断变化。**
+
+很多朋友看到“避免重复造轮子”就以为中台把轮子造好了，业务方只管用就可以了，而实际情况是中台确实把轮子造好了，但是它每隔一段时间就会把轮子换一遍，例如中台的数据模型、接口、架构等其实都是需要根据业务发展不断变化的。
+
+为了达到中台“复用”的目标，通常情况下中台在推出新轮子后，就不会再长期维护老轮子，否则如果中台同时维护4~5个相似的轮子，复用就无从谈起。这就要求基于中台的业务都必须在某个时间段内完成轮子的切换，相当于是业务方进行了一次被动架构演进。
+
+当然，如果没有中台，业务方的架构肯定也要随着业务的发展而演进，那这和跟随中台被动演进有什么区别呢？最主要的区别是中台的架构演进频率会比独立的业务架构演进要快，道理很简单：中台融合了多个相似业务的发展！
+
+举个简单例子：如果中台支持10个业务，其中有1个业务发展很快，中台就必须跟着演进，剩余的9个业务即使没有任何发展，也必须跟着被动演进！更何况如果这10个业务本身都在不断发展，那中台的演进会更快！那是否存在某种牛逼的技术，让中台的演进不影响业务呢？绝大部分情况下都不可能，这是由中台演进的本质决定的：中台演进的绝大部分动力来源于业务，它的演进不可能做到反过来不影响业务。这点和技术平台（存储、消息队列这类）不一样，技术平台演进的动力来源于技术更新，是可以做到不影响业务的。
+
+**4.  中台是某类业务的中台，不是所有业务的中台。**
+
+中台的本质是提炼共性需求复用，如果业务差异太大的话，复用度不高，提炼和维护中台花费的代价抵不上中台复用带来的价值。所以，实际上应该叫“电商中台”、“支付中台”、“物流中台”、“出行中台”、“视频中台”、“保险中台”，而不应该是“阿里中台”、“腾讯中台”、“百度中台”、“滴滴中台”。
+
+当然，因为现在“中台”概念火爆，出现了原来很多做中间件和技术平台的团队，纷纷将自己负责的“XX平台”改为“技术中台”，从广义的角度来说也可以，因为这确实是“各业务线共性需求”，毕竟存储、缓存、消息队列这些肯定是各业务线的共性需求，但通常情况下我们说中台时所指的“需求”，还是指“业务需求”，即客户可以使用到的功能。
+
+所以，即使只是看到“茅台云商”这种中台项目的PPT，也能大概率地推断这个项目失败的可能性会非常高（图片来源：[中台，我信了你的邪 | 深氪](https://mp.weixin.qq.com/s/9j3BnR3UqA-lnJDoM5Hrvg)）：
+
+<img src="https://static001.geekbang.org/resource/image/d9/06/d90c0d13a10b8aaf5364ee7199eaee06.jpeg" alt="">
+
+## 中台的效果是怎样的？
+
+关于中台的效果，你看到的是这样的（摘自《[中台的问题，是技术的问题，还是人的问题](https://mp.weixin.qq.com/s/rHe1nf3jrGxoyZmWt-R25g)》）：
+
+因为阿里巴巴的生态非常复杂，很多业务方本身也很年轻，要怎么去做，下层到底能提供什么样的支撑是不清楚的。当有大中台思路之后，第一，我们这个体系里有什么样的能力，可以让各业务很清楚地知道，也可以让前台业务方更快的理解、选择和使用中台能力。第二、我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。
+
+实际的中台是这样的。
+
+**1.  中台的体系有什么样的功能，业务方根本不是很清楚地知道，而是很清楚地不知道。**
+
+事实上，几乎没有人能完整地知道中台里面各个域各个子系统的能力，更加谈不上业务方更快的理解、选择和使用了。你可以随便打开一张某个技术大会上分享的中台架构，满满的一页甚至几页PPT，大框小框几十上百个，对应到具体的线上运行的系统可能几百上千个，这么复杂的一个系统，怎么可能有人知道所有的功能和细节？更何况是业务方了。
+
+至于说中台提供完整的解决方案，业务方只要定制一下就可以快速上线，说起来容易做起来难，除非业务方是准备复制一个和已有业务基本一样的业务，否则基本上是不可能实现的。原因在于中台提供的解决方案，必然是基于已有的业务来抽象出来的“共性需求”的大集合，如果这个解决方案可定制化度很高，那么就说明可复用度比较低；如果这个解决方案的可定制化度很低，虽然可复用度高但业务可扩展度比较低。
+
+而从中台的本质出发，中台必然会选取“可定制度低可复用度高”的方向，这就约束了只有复制一个非常类似的新业务的时候中台的解决方案才有很大价值，但是对于同一个公司来说，为何要复制两个基本一样的业务呢？如果真的有中台选择了“可定制度高”的解决方案，当新业务和已有业务有较大差异的时候，中台的解决方案并没有什么很大价值，因为大量的工作量会耗费在定制那部分。
+
+实际上我接触的中台是这样运作的：中台会分为很多“域”，例如“交易”、“搜索”、“会员”等，然后业务方将自己的业务需求写出来，然后拉上各个域的产品接口人和技术接口人，一个域一个域的讨论。
+
+以“会员域”为例，讨论的时候，会员域的产品接口人技术接口人肯定很熟悉会员的功能、模型和接口，业务方需要跟中台子域接口人讲解业务需求，然后中台子域接口人来评估会员当前的能力哪些是支持的，哪些是不支持的，不支持的部分是属于共性需求还是属于个性需求，如果是共性需求，需要给出中台的修改的方案，而且修改方案还要会员域的架构师进行评审，因为改中台是影响所有业务的；如果是个性需求，需要设计出中台和业务方交互的方式，例如是提供接口、配置、扩展包等。
+
+所以如果你真正基于中台做过项目你就会发现，编码的时间确实少了，但是前期的沟通和后期的联调非常耗时间，随便做个什么项目，拉上20~30人算一般的，稍微大点的项目拉上50~100人也是很正常的。
+
+以淘宝的中台为例，如下是淘宝电商中台共享事业部里面交易中心的结构（图片来源：《企业IT 架构转型之道》）：
+
+<img src="https://static001.geekbang.org/resource/image/dc/aa/dc8444a244aed455e92ddd77f9bfdbaa.png" alt="">
+
+注意：交易中心只是共享事业部的一个业务域，同级别的业务域从公开资料来看有10来个，而交易中心内部就有13个子功能了，这些子功能最后都可能对应1个或者多个实际运行的系统。
+
+**2.  中台的所谓的“快”，并没有严谨的衡量。**
+
+目前各类文章都会说有了中台后业务开发快，但并没有详细的案例和分析到底有多快，仅有的几个案例看起来很夸张，但没有详细背景描述其实并没有说服力。例如说某个业务新上线很快，到底是因为第一版功能很简单，还是第一个版本投入了大量的人力来做，还是真的是因为用了中台？
+
+事实上我经历过的两个接入中台项目并不能看出来快，从实际的开发经验来看，业务方和中台的需求讲解和讨论，业务方和中台方案的设计讨论，后期的业务系统和中台系统联调这些工作量并没有减少，反而还会有一定程度的增加，因为中台在分析需求、设计方案、联调测试的时候需要考虑对其它业务的影响。
+
+中台能够带来的效率提升主要体现在两方面：一是编码的工作量确实会少，毕竟还是有大量的代码可以重用的；二是中台的人员都对已有的类似业务和技术很熟悉，需求的确认和方案的设计会更高效，全流程综合来看，很难判断效率到底高还是低。
+
+事实上我之前在阿里游戏做过几个从0到1的项目，因为老板重视，都是将原来类似的系统已有的核心开发人员拉过去开发新项目，最初的代码也是从原系统拷贝过去改，开发效率一样很高，核心原因简单来说就是“熟手开发”。
+
+以上是我从基于中台的开发项目中观察到的一些问题，归纳总结出来的一些经验。总体来看好像我在质疑中台，其实不然。关于中台的好处已经有太多的文章了，这一讲试图提供从使用者的视角来看中台所看到的一些信息和问题，目的在于帮助大家更加全面地了解中台。
+
+咱们这门“从零开始学架构”的课程提到了架构设计的三原则，第一条就是“合适原则”，这个原则对中台也是适应的。总结来说就是：中台不是灵丹妙药，不要有问题就想着用中台解决；中台也不是放之四海而皆准，明确中台的适应场景和可能的坑，才能更好地落地中台！
+
+其实提出中台的逍遥子已经早就谆谆告诫了（来源《[中台，我信了你的邪 | 深氪](https://mp.weixin.qq.com/s/9j3BnR3UqA-lnJDoM5Hrvg)》）：
+
+> 
+中台并不适用于每家公司的每个阶段。在独立业务拓展期、突破期，“一定用独立团、独立师、独立旅建制来做”，否则就会变成瓶颈；但发展到一定阶段，出现太多山头时，就要“关停并转、要合并同类项。问管理要效率，取消重复性建设”。
+
+
+好了，关于中台的分享就到这里。听了今天的内容，你对中台有更多理解了吗？欢迎留言区分享你的思考，我们一起交流。

极客时间专栏/从0开始学架构/特别放送/如何高效地学习开源项目 | “华仔，放学别走！” 第3期.md

@@ -0,0 +1,154 @@
+<audio id="audio" title="如何高效地学习开源项目 | “华仔，放学别走！” 第3期" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/21/49/2116f1bfa7286411ad127541cd87cd49.mp3"></audio>
+
+你好，我是华仔。今天这期“特别放送”，我想和你聊聊如何高效地学习开源项目，一方面澄清开源项目学习过程中的几个误区，另一方面谈谈我自己具体实践时的一套方法论。
+
+得益于开源运动的蓬勃发展，众多技术顶尖的公司、团队或者个人通过开源的方式向技术社区贡献了许多优秀的开源项目，一方面大大促进了整体技术的发展，另一方面大大减轻了中小公司和团队在技术方面的投入压力，让团队能够更加聚焦于业务。
+
+开源项目对团队和业务有很大好处，但对于技术人员来说，如果只是简单的采取“拿来主义”，那就变成一个陷阱：看似很快的用开源项目实现了需求，但自己的技术水平并没有什么提升；甚至可能出现看起来用了很多开源项目，知道很多项目名称，但技术水平止步不前的窘境。
+
+因此，对于开源项目，不能简单的采取“拿来主义”，而要比较深入的去学习开源项目，做到“知其然，知其所以然”，一方面是为了更好地应用这些开源项目，另一方面也是为了通过学习优秀的开源项目来提升自己的能力。
+
+很多技术同学确实也想深入学习一些业界成熟和优秀的开源项目，例如Nginx、Redis、Netty等，但是在具体实践的时候，常常因为一些不正确的观点而误入歧途，例如：
+
+<li>
+只有开发这些开源项目的人才能真正理解，我没法参与这个项目开发，因此我很难深入理解。
+</li>
+<li>
+我的项目没有用Redis，不用的话很难深入理解。
+</li>
+<li>
+数据结构和算法很重要，所以我只要研究其数据结构和算法就够了，例如Nginx用的红黑树。
+</li>
+<li>
+“Talk is cheap, show me the code”，一头扎进源码逐行阅读。
+</li>
+
+这些观点要么让自己望而生畏从而轻易放弃，要么让自己浪费大量时间而没有多大收获。那究竟要怎样做才是正确的呢？下面我结合自己的经验谈谈我对如何学习开源项目的看法。
+
+- 首先，需要树立正确的观念：**不管你是什么身份，都可以从开源项目中学到很多东西**。
+
+例如，要理解Redis的网络模型，我们不需要成为Redis的开发者，也不需要一定要用到Redis，只要具备一定的网络编程基础，再通过阅读Redis的源码，都可以学习Redis这种单进程的Reactor模型。
+
+- 其次，**不要只盯着数据结构和算法**，事实上这两点在学习开源项目的时候并没有那么重要。
+
+例如，Nginx使用红黑树来管理定时器，对于绝大部分人来说，只要知道这点就够了，并不需要去研究Nginx实现红黑树的源码是如何写的，除非你需要修改这部分，但我认为极少人会有这个需求。
+
+- 第三，采取“自顶向下”的学习方法，**源码不是第一步，而是最后一步**。
+
+不要一上来就去看源码，而是要基本掌握了功能、原理、关键设计之后再去看源码，看源码的主要目的是为了学习其代码的写作方式，以及关键技术的实现。
+
+例如，Redis的RDB持久化模式“会将当前内存中的数据库快照保存到磁盘文件中”，那这里所谓的“数据库快照”到底是怎么做的呢？在Linux平台上其实就是fork一个子进程来保存就可以了；那为何fork子进程就生成了数据库快照了呢？这又和Linux的父子进程机制以及copy-on-write技术相关了。
+
+通过这种方式，既能够快速掌握系统设计的关键点（Redis的RDB模式），又能够掌握具体的编程技巧（内存快照）。
+
+接下来我详细谈谈“自顶向下”的学习方法和步骤。
+
+## 第一步：安装
+
+很多人看到“安装”这个步骤都可能会觉得有点不以为然：“不就是对照手册执行一下命令么，没什么技术含量，用的时候装一下就可以了”。事实上，安装步骤远远不止这么简单，通过具体的安装过程，你可以获取到如下一些关键信息：
+
+- 这个系统的依赖组件，而依赖的组件是系统设计和实现的基础
+
+以Nginx为例，源码安装Nginx依赖的库有pcre、pcre-devel、openssl、openssl-devel、zlib，光从名字上看都能够了解一些信息，例如openssl可能和https有关，zlib可能和压缩有关。
+
+再以Memcache为例，最大的依赖就是libevent，而根据libevent是一个高性能的网络库，我们就能大概推测Memcache的网络实现应该是Reactor模型的。
+
+- 安装目录也能够提供一些使用和运行的基本信息
+
+例如，Nginx安装完成后，目录如下：
+
+<img src="https://static001.geekbang.org/resource/image/f1/d5/f1f6517e0640b015bec016ce17b4d7d5.png" alt="">
+
+这个目录提供的信息有：conf是存放配置文件的，logs是存放日志的，sbin是运行程序，但是html是什么呢？这个疑问会促使你继续去研究和学习。
+
+再来看看Redis，安装完成后，目录下只有一个bin目录，具体如下：
+
+<img src="https://static001.geekbang.org/resource/image/bf/14/bff3dd630e3091d7a247db0bdef97814.png" alt="">
+
+我相信大部分人看到这目录都会感到有点惊讶：这也太简单了吧，尤其是与Nginx相比！因此也会自然而然的有一些疑问，例如Redis如何配置？Redis日志保存在哪里？这些疑问同样会促使你继续去研究和学习，**带着问题去学习效率是最高的**。
+
+- 系统提供了哪些工具方便我们使用
+
+同样以Redis为例，你可以看到redis-benchmark、redis-check-aof等程序，从名字能够大概猜出这些工具的基本使用场景，而这些工具在后面故障定位和处理、性能测试等场景可能非常方便。
+
+## 第二步：运行
+
+安装完成后，我们需要真正将系统运行起来，运行系统的时候有两个地方要特别关注：**命令行和配置文件**，它们主要提供了两个非常关键的信息：系统具备哪些能力和系统将会如何运行。这些信息是我们窥视系统内部运行机制和原理的一扇窗口。
+
+例如，下面是Memcache的启动参数一部分：<br>
+<img src="https://static001.geekbang.org/resource/image/0b/74/0be9e5168f5c45c20197152cccd6f874.png" alt="">
+
+通过这几个启动参数，你可以获取如下一些信息：
+
+<li>
+Memcache支持UNIX socket通信和TCP通信。
+</li>
+<li>
+Memcache可以指定内存大小。
+</li>
+<li>
+lock memory看起来和内存有关，但具体是什么意思？配置和不配置有什么区别么？
+</li>
+
+通常情况下，如果我们将每个命令行参数和配置项的作用和原理都全部掌握清楚了的话，基本上对系统已经很熟悉了。我的一个习惯是不管三七二十一，先把所有的配置项全部研究一遍，包括配置项的原理、作用、影响，并且尝试去修改配置项然后看看系统会有什么变化。例如，将Memcache的“–conn-limit”改为1后，查看多个连接请求时Memecache会返回什么错误、记录什么日志等。
+
+## 第三步：原理研究
+
+完成前两个步骤后，我们对系统已经有了初步的感觉和理解，此时可以更进一步去研究其原理。其实在研究命令行和配置项的时候已经涉及一部分原理了，但是还不系统，因此我们要专门针对原理进行系统性的研究。这里的关键就是“**系统性**”三个字，怎么才算系统性呢？主要体现在如下几个方面：
+
+- 关键特性的基本实现原理
+
+每个流行的开源项目之所以能够受到大众的欢迎，肯定是有一些卖点的，常见的有高性能、高可用、可扩展等特性，那到底这些项目是如何做到其所宣称的那么牛的呢？这些牛X的技术实现就是我们要学习的地方。
+
+例如，Memcache的高性能具体是怎么做到的呢？首先是基于libevent实现了高性能的网络模型，其次是内存管理Slab Allocator机制。为了彻底理解Memcache的高性能网络模型，我们需要掌握很多知识：多路复用、Linux epoll、Reactor模型、多线程等，通过研究Memcache的高性能网络模型，我们能够学习一个具体的项目中如何将这些东西全部串起来实现了高性能。
+
+再以React为例，Virtual DOM的实现原理是什么、为何要实现Virtual DOM、React是如何构建Virtual DOM树、Virtual DOM与DOM什么关系等，通过研究学习Virtual DOM，即使不使用React，我们也能够学习如何写出高性能的前端的代码。
+
+- 优缺点对比分析
+
+这是我想特别强调的一点，**只有清楚掌握技术方案的优缺点后才算真正的掌握这门技术，也只有掌握了技术方案的优缺点后才能在架构设计的时候做出合理的选择**。
+
+优缺点主要通过对比来分析，即：我们将两个类似的系统进行对比，看看它们的实现差异，以及不同的实现优缺点都是什么。
+
+典型的对比有Memcache和Redis，例如（仅举例说明，实际上对比的点很多），Memcache用多线程，Redis用单进程，各有什么优缺点？Memcache和Redis的集群方式，各有什么优缺点？
+
+即使是Redis自身，我们也可以对比RDB和AOF两种模式的优缺点。
+
+在你了解了什么是“系统性”后，我来介绍一下原理研究的手段，主要有三种：
+
+<li>
+通读项目的设计文档：例如Kafka的设计文档，基本涵盖了消息队列设计的关键决策部分；Disruptor的设计白皮书，详细的阐述了Java单机高性能的设计技巧。
+</li>
+<li>
+阅读网上已有的分析文档：通常情况下比较热门的开源项目，都已经有非常多的分析文档了，我们可以站在前人的基础上，避免大量的重复投入。但需要注意的是，由于经验、水平、关注点等差异，不同的人分析的结论可能有差异，甚至有的是错误的，因此不能完全参照。一个比较好的方式就是多方对照，也就是说看很多篇分析文档，比较它们的内容共同点和差异点。
+</li>
+<li>
+Demo验证：如果有些技术点难以查到资料，自己又不确定，则可以真正去写Demo进行验证，通过打印一些日志或者调试，能清晰的理解具体的细节。例如，写一个简单的分配内存程序，然后通过日志和命令行（jmap、jstat、jstack等）来查看Java虚拟机垃圾回收时的具体表现。
+</li>
+
+## 第四步：测试
+
+通常情况下，如果你真的准备在实际项目中使用某个开源项目的话，必须进行测试。有的同学可能会说，网上的分析和测试文档很多，直接找一篇看就可以了？如果只是自己学习和研究，这样做是可以的，因为构建完整的测试用例既需要耗费较多时间，又需要较多机器资源，如果每个项目都这么做的话，投入成本有点大；但如果是要在实践项目中使用，必须自己进行测试，因为网上搜的测试结果，不一定与自己的业务场景很契合，如果简单参考别人的测试结果，很可能会得出错误的结论。例如，开源系统的版本不同，测试结果可能差异较大。同样是K-V存储，别人测试的value是128字节，而你的场景value都达到了128k字节，两者的测试结果也差异很大，不能简单照搬。
+
+测试阶段需要特别强调的一点就是：**测试一定要在原理研究之后做，不能安装完成立马就测试！**原因在于如果对系统不熟悉，很可能出现命令行、配置参数没用对，或者运行模式选择不对，导致没有根据业务的特点搭建正确的环境、没有设计合理的测试用例，从而使得最终的测试结果得出了错误结论，误导了设计决策。曾经有团队安装完成MySQL 5.1后就进行性能测试，测试结果出来让人大跌眼镜，经过定位才发现innodb_buffer_pool_size使用的是默认值8M。
+
+## 第五步：源码研究
+
+源码研究的主要目的是学习原理背后的具体编码如何实现，通过学习这些技巧来提升我们自己的技术能力。例如Redis的RDB快照、Nginx的多Reactor模型、Disruptor如何使用volatile以及CAS来做无锁设计、Netty的Zero-Copy等，这些技巧都很精巧，掌握后能够大大提升自己的编码能力。
+
+通常情况下，**不建议通读所有源码**，因为想掌握每行代码的含义和作用还是非常耗费时间的，尤其是MySQL、Nginx这种规模的项目，即使是他们的开发人员，都不一定每个人都掌握了所有代码。带着明确目的去研究源码，做到有的放矢，才能事半功倍，这也是源码研究要放在最后的原因。
+
+对于一些基础库，除了阅读源码外，还可以自己写个Demo调用基础库完成一些简单的功能，然后通过调试来看具体的调用栈，通过调用栈来理解基础库的处理逻辑和过程，这比单纯看代码去理解逻辑要高效一些。例如，下面是Netty 4.1版本的telnet服务器样例调试的堆栈，通过堆栈我们可以看到完整的调用栈：<br>
+<img src="https://static001.geekbang.org/resource/image/39/01/39a4686fe72c89e5047aeeeeec73aa01.png" alt="">
+
+## 时间分配
+
+前面介绍的“自顶向下”5个步骤，完整执行下来需要花费较长时间，而时间又是大部分技术人员比较稀缺的资源。很多人在学习技术的时候都会反馈说时间不够，版本进度很紧，很难有大量的时间进行学习，但如果不学习感觉自己又很难提升？面对这种两难问题，具体该如何做呢？
+
+通常情况下，**以上5个步骤的前3个步骤，不管是已经成为架构师的技术人员，还是立志成为架构师的技术人员，在研究开源项目的时候都必不可少**；第四步可以在准备采用开源项目的时候才实施，第五步可以根据你的时间来进行灵活安排。这里的“灵活安排”不是说省略不去做，而是在自己有一定时间和精力的时候做，因为只有这样才能真正理解和学到具体的技术。
+
+如果感觉自己时间和精力不够，与其蜻蜓点水每个开源项目都去简单了解一下，还不如集中精力将一个开源项目研究通透，就算是每个季度只学习一个开源项目，积累几年后这个数量也是很可观的；而且一旦你将一个项目研究透以后，再去研究其他类似项目，你会发现自己学习的非常快，因为共性的部分你已经都掌握了，只需要掌握新项目差异的部分即可。
+
+今天，我给你分享了我对于学习开源项目的看法和步骤，希望对你有所帮助。如果你在工作、学习中遇到什么问题，不论是技术、管理或者其他方面，欢迎在“特别放送”里给我留言，可能你的问题就是“华仔，放学别走！第4期”的主题。
+
+最后到了送福利的时间，14～25期入选精选留言的用户是@漆～心endless、@明日之春、@鹅米豆发、@loveluckystar、@肖一林、@衣申人、@plflying、@正是那朵玫瑰、@Leon Wong、@孙振超、@yason li、@gen_jin，送给你们价值68元的专栏阅码。也感谢所有留言的同学，你的想法不仅让自己加深了对问题的思考，也能帮助到其他同学一起进步。

极客时间专栏/从0开始学架构/特别放送/新书首发 | 《从零开始学架构》.md

@@ -0,0 +1,14 @@
+
+你好，我是李运华。在完成「从0开始学架构」专栏后，今天又有一件意义重大的事想与你分享，那就是我的新书《从零开始学架构》出版了，并且已经提前上架极客商城。
+
+从书名你可以看出来，这本书脱胎于我的专栏，书中涵盖了专栏所有精华内容，经过我的重新梳理，这本书会显得更加紧凑，相信一定可以让你耳目一新。
+
+我的专栏有超过2.6万同学一起学习，你们的留言总是可以让我重新思考过去我所掌握的技术，也为这本书的优化提供了很多建议，**可以说这也是我和你共同完成的图书，这本书的问世，离不开你的帮助**。
+
+对已经订阅了专栏的同学来说，《从零开始学架构》这本书的内容我就不多赘述了。作为一本纸质图书，它可以和专栏组成一套完整的学习体系，专栏的音频和图文结合纸质图书的阅读体验，**这种学习方式是非常有效的**，所以我也一直期待这本书可以尽快出版。
+
+《从零开始学架构》现已在极客商城提前预售，作为订阅专栏的老同学，我给你申请了**专属优惠码**，可以与限时优惠价叠加使用，你可以在极客商城待付款订单中点击“使用优惠”，输入优惠码“jiagou”，在结算时再减6元。
+
+最后，我还是要感谢你跟我一起创作了这本书，**技术成就梦想，坚持就能成功**。
+
+[<img src="https://static001.geekbang.org/resource/image/f1/ce/f1b6d7ac4a05aa17cfb90f8bb66f05ce.jpg" alt="unpreview">](time://mall?url=https%3A%2F%2Fh5.youzan.com%2Fwscshop%2Fgoods%2F2oghqbo0qugbs%3Fdc_ps%3D2089737893579973633.200001%26from%3Dsinglemessage)

极客时间专栏/从0开始学架构/特别放送/架构专栏特别放送 | “华仔，放学别走！” 第2期.md

@@ -0,0 +1,87 @@
+
+各位同学，晚上好，我是架构专栏的编辑Shawn。今天又到周五啦，没错，我又出来送福利了[捂脸]。
+
+[“华仔，放学别走”第1期](http://time.geekbang.org/column/article/7647)不知道你看了没有，华仔回答了关于知识分享、理论与实践、专栏学习方法、推荐的参考书等几个问题，希望你从中能够有所收获。今天是“华仔，放学别走”第2期，继续回答你所关注的问题，然后展示出08 ~ 13期被选中的精选留言，并给留言被选中的同学送出价值68元的专栏阅码。话不多说，开始今天的问答环节。
+
+Shawn：有做公司架构/网站架构/App架构的同学，这个专栏能帮助到他们吗？
+
+华仔：有的同学在学习了一段时间后跟我留言交流，说感觉专栏的内容好像比较适合做互联网后台架构，不太适合企业应用、客户端这类系统。其实这是一个误解，我之所以在前面花费很大篇幅来讲架构设计的目的、架构设计原则、架构设计流程等看起来比较偏理论的内容，而没有一上来就讲异地多活、高性能架构之类的怎么做，原因就在于**这是一套完整的架构设计理论体系**，不管是企业应用，还是客户端应用，都可以按照这个设计理论体系去操作。我以手机App为例，首先，我们分析一下App的复杂度主要来源是什么？通常情况下，App的主要复杂度就是可扩展，因为要不断地开发新的需求；高性能和高可用也涉及，高性能主要和用户体验有关；高可用主要是减少崩溃。其次，再看App的架构需要遵循架构设计原则么？答案是肯定需要。刚开始为了业务快速开发，可能用“原生+H5”混合架构；后来业务发展，功能更复杂了，H5可能难以满足体验，架构又需要演进到“纯原生”；如果业务再发展，规模太庞大，则架构又可能需要演进到“组件化、容器化”。以上通过手机App的为例说明这套架构设计理论是通用的，有兴趣的同学可以按照这种方式分析一下企业应用，会发现这套理论也是适应的。
+
+Shawn：讲讲你总结“架构设计三原则”的过程吧？
+
+华仔：“架构设计三原则”是综合各方面的信息和思考得来的。首先是我自己的经验，包括成功的经验和失败的教训；其次是分析了很多业界的架构演讲和技术发展历史；第三是看了一些关于技术本质的书籍而受到的启发，例如《技术的本质》《系统之美》等。其实最初整理的架构设计原则有10多条，但我觉得10多条太多了，不聚焦也不利于理解，因此去芜存菁，最终得到了“架构设计三原则”，这三个原则是最重要也是最核心的。
+
+如下是我原来整理的设计原则，可以看到一共有14条：
+
+<img src="https://static001.geekbang.org/resource/image/3b/52/3b9c59fa4b921f6d62530cfe3eb74f52.jpg" alt="" />
+
+Shawn：“PPT架构师”的口头禅是“细节不讨论”，一个优秀的架构师，需要对细节有多少考虑呢？
+
+华仔：这是一个非常好的问题，也是很多同学困惑的问题，我分享一下我的做法，以我学习Elasticsearch为例，具体的做法是：
+
+<li>
+搭建一个单机伪集群，搭建完成后看看安装路径下的文件和目录，看看配置文件有哪些配置项，不同的配置项会有什么样的影响。
+</li>
+<li>
+执行常用的操作，例如创建索引，插入、删除、查询文档，查看一下各种输出。
+</li>
+<li>
+研究其**基本原理**，例如索引、分片、副本等，研究的时候要多思考，例如索引应该如何建，分片数量和副本数量对系统有什么影响等。
+</li>
+<li>
+和其他类似系统对比，例如Solr、Sphinx，研究其**优点、缺点、适用场景**。
+</li>
+<li>
+模拟一个案例看看怎么应用。例如，假设我用Elasticsearch来存储淘宝的商品信息，我应该如何设计索引和分片。
+</li>
+<li>
+查看业界使用的案例，思考一下别人为何这么用；看看别人测试的结果，大概了解性能范围。
+</li>
+<li>
+如果某部分特别有兴趣或者很关键，可能去看源码，例如Elasticsearch的选举算法（我目前还没看^_^）。
+</li>
+<li>
+如果确定要引入，会进行性能和可用性测试。
+</li>
+
+这样一套组合拳下来，基本上能够满足在架构设计时进行选型判断，而且花费的时间也不多。我并不建议拿到一个系统一开始就去读源码，效率太低，而且效果也不好。
+
+Shawn：谈谈架构师沟通能力的重要性吧？
+
+华仔：架构师是业务和技术之间的桥梁，同时通常情况下还会确定整体项目的步骤。因此，架构师的沟通能力非常重要，既要说得动老板，让老板支持自己的设计决定；又要镇得住技术人员，让技术人员信服自己的设计选择；同时还要能够理解业务，结合业务不同发展阶段设计合适的架构，所以也要参与产品和项目决策。由于架构设计过程中存在很多判断和选择，而且不一定都有明确量化的标准，因此不同的人有不同的看法是普遍情况。这种情况下架构师既需要专业能力过硬，又需要具备良好的沟通技巧，才能促使业务、项目、技术三方达成一致。
+
+当然，**架构师的核心能力还是技术能力，过硬的技术才是良好沟通的基础**，否则单纯靠沟通技巧甚至花言巧语，一次两次可能奏效，但后面被打脸打多了，也就没人信任了。
+
+Shawn：有同学留言说，给企业做项目，甲方会不顾业务需要，只要是业界流行的技术就要求在项目中采用，这种情况下怎样才能符合“架构设计三原则”？
+
+华仔：首先，业务第一，先把订单签下来，才有后面的架构设计，如果硬要说甲方的要求不合理，不满足“架构设计三原则”，结果订单都拿不到，那是没有意义的。其次，这种情况我把它归为“架构约束”，即这不是架构师能够选择的，而是架构师必须遵守的，因此这里不需要使用“架构设计三原则”来判断。第三，这种情况下，架构师还是可以应用“架构设计三原则”来指导架构设计，比如说客户要求采用Docker，Docker的网络模式有5种，host模式使用起来比bridge模式简单，那我们就用host模式；如果客户再要求需要对Docker进行统一管理，那我们是自己研发Docker管理平台，还是直接用Kubernetes呢？按照简单原则来说，肯定用Kubernetes了。
+
+通过这个示例也可以看出，“架构设计三原则”主要是指架构师在选择和判断时采取的指导原则；但如果是架构的基本需求或者约束必须被满足时，架构师此时的选择是采取什么样的方案能够更好的满足这些需求和约束。
+
+## 留言精选
+
+<img src="https://static001.geekbang.org/resource/image/4b/a3/4b3f1ab66a7c470970c67da62ec99da3.jpeg" alt="" />
+
+华仔：有个懂技术的好老大是一件多么幸福的事情：）
+
+<img src="https://static001.geekbang.org/resource/image/7c/9c/7ce774f26c16292a596ac4489c60369c.jpeg" alt="" />
+
+华仔：有钱也不能任性，微软95年也不可能开发出Windows 10操作系统；业务量大了重构甚至重写那是自然而然的，不会浪费也不会导致错失产品机会，Windows、Android、淘宝、QQ都是这么过来的。
+
+<img src="https://static001.geekbang.org/resource/image/40/8c/402a833915524ab1b572da8ddc34ab8c.jpeg" alt="" />
+
+华仔：终于明白了我一开始就提架构设计的核心目的的良苦用心了吧 ：）
+
+<img src="https://static001.geekbang.org/resource/image/06/bf/06fa4a874cda142e768f64260087a4bf.jpeg" alt="" />
+
+华仔：实现起来细节较多，但没有想象的那么复杂，一般的公司如果有人力的话，做一个简单够用的消息队列不难，用MySQL做存储的话，不到1万行代码就可以搞定。
+
+<img src="https://static001.geekbang.org/resource/image/48/d7/48e3036370c23ad5cd84b5aeb7a48fd7.jpeg" alt="" />
+
+华仔：如有雷同，实属巧合，确认过眼神，我不是你们公司的人 ^_^
+
+<img src="https://static001.geekbang.org/resource/image/9a/6e/9ad8b84a03ab5f9679e0596216f4f56e.jpeg" alt="" />
+
+华仔：架构师确实需要在技术广度和技术深度两方面都要兼顾，但如何把握技术深度这个“度”，不同架构师有不同的理解，但千万不能说“细节不讨论”“你上网搜”，这样会没有技术公信力。
+
+最后，再次恭喜@Tony、@Michael、@空档滑行、@bluefantasy、@东、@ant，也感谢写下留言的每位同学。欢迎你在这期“华仔，放学别走”留下你的问题，业务、职场、职业规划等不限主题，可以和华仔一起聊聊专栏以外的话题。

极客时间专栏/从0开始学架构/特别放送/架构专栏特别放送 | “华仔，放学别走！”第1期.md

@@ -0,0 +1,80 @@
+
+各位同学，晚上好，我就是那位在每期专栏最后都会乱入进来的编辑Shawn[捂脸]，对，我是来送福利的。
+
+“从0开始学架构”专栏已经更新了9期，概念和基础已经讲了不少，不知道你掌握的如何呢？每期华仔都会在最后提出一个思考题，希望能让你在学习后有一个思考提升的过程，既可以记下心得体会，也许还能碰撞出新的想法。
+
+以周为单位，今天我会让华仔选出01-07期的优质精选留言，送给入选的同学价值68元的专栏阅码作为鼓励。入选的留言的标准既可以是经过深度思考的回答，也可以是对其他同学有启发的经验分享，更可以是产生共鸣的疑问。
+
+在公布上榜精选留言前，应广大同学的强烈呼声**“华仔，放学别走！”**，问他几个在评论中大家普遍感兴趣的问题。
+
+Shawn：看到有同学提到“能看到资深技术专家的分享实属不易，感觉自己像是站在巨人的肩膀上学习，机会难得”，华仔你是怎么看待知识分享的？
+
+华仔：首先，知识分享能够促进知识的传播和发展，其实我们都是站在前人的肩膀上才能有今天的成就；其次，知识分享对于作者来说也是一个自我提升的过程，很多知识和技术，没分享出来的时候我觉得自己很清楚了，但真正去写才会发现，这里有个细节没考虑，那里有个疑问需要澄清，只有真正写完了才会觉得自己基本掌握了；同时分享出去后，会有很多读者帮忙审核检阅，会提出自己的一些看法，通过这些交流又能够进一步加深理解。
+
+所以很多朋友问我**怎么提升技术，我推荐的一个方法就是写博客**，既能够加深自己对知识的理解，又能够锻炼自己的表达能力，还能够磨练自己的意志力（坚持写很不容易），一举三得。某个方面的博客写多了，也许哪天你也能够出一个专栏。
+
+Shawn：华仔，现在专栏更新到第9期，还在讲理论和基础，已经有同学提出想学实战技巧，你怎么看待理论与实践之间的关系？
+
+华仔：架构设计也需要知行合一，知是行之始，行是知之成，所以我在开始的时候讲述了架构设计相关的理论知识，例如架构设计的本质、目的、原则等，只有掌握了这些内容，才能在架构设计实践的时候有理可依有据可循，而不是凭感觉、拍脑袋、照猫画虎等。其实架构设计和编程一样，我们要学Java编程，肯定要先熟悉Java的语法、API，然后才能开始编码，再通过实际编码实践加深对这些理论知识的理解。
+
+我在带团队的时候，发现很多技术人员在做架构设计的时候，最缺乏的就是架构设计的理论体系，在设计的时候摸着石头过河，踩了一个坑就积累了一点经验，但是下次换个业务换个场景，又要踩其他坑。这也是我萌生写这样一个专栏的一个推动因素，因为我们的学校没有教架构相关的课程，架构领域也缺乏经典的体系化的书籍，导致技术人员在架构方面的能力提升速度较慢。
+
+具体的实战技巧其实不用担心，专栏后面的内容大部分都是讲具体的实战技巧，例如高性能架构模式、高可用架构模式、FMEA、CAP、异地多活、互联网架构演进等。
+
+Shawn：介绍一下你每天学习新知识的方式吧，或者你觉得怎样学习你的架构专栏，效果会更好？
+
+华仔：我是坐地铁上班，一般我都是在地铁上看书或者看专栏，晚上睡觉前和周末也会挤出时间来看书或者学习，更详细的做法可以参考我的一个公开演讲稿[《吃的草够多，你也能成为大牛》](http://zhuanlan.zhihu.com/p/22436213)。
+
+我的专栏是我自己多年经验和思考的总结积累，是一套完整的架构设计方法论，涵盖的内容较多，所以要想学好，**首先不能着急**，循序渐进，争取每篇都有一些收获，可以**尝试写一些笔记、心得**；**其次需要知行合一**，学习了专栏的内容后，尽量结合自己的业务和系统，尝试拿这套方法论去分析，看看有什么收获或者疑问，注意并不是一定要亲自做架构才能实践，针对已有的系统进行分析，学习业界已有的架构案例都可以，当然如果有实践机会那就更好；**第三多交流**，一个人的思维难免有局限性和思维盲点，如果能和同事或者朋友一起学习，然后一起讨论，互相印证，效果会更好。
+
+Shawn：总有同学在问专栏以外有没有推荐的参考书或资料，华仔能不能推荐几种？
+
+华仔：技术方面我推荐**《UNIX编程艺术》**，这本书里面的思想和原则，无论对于编码还是架构设计都很有指导意义。
+
+个人成长方面我推荐**《异类》**，这本书通过很多的案例来说明究竟怎么样才能成功，10000小时理论只是其中的一部分，还有很多有趣的发现，例如如何才算赢在起跑线上等。
+
+人生境遇方面我推荐**《羊皮卷》**，其中有一篇《选择的力量》，我看了后醍醐灌顶，真的是就像佛家禅宗说的突然“悟道”一样深受启发，从此以后很多为人处世方式都因此而改变了。
+
+Shawn：看到那么多同学的留言，有什么想说的吗？
+
+华仔：非常感谢每一位同学的积极参与，很多同学留言表示感谢，让我感到很开心，说明专栏能够真正帮助大家学习架构设计的技术和提升自己的能力。
+
+很多同学的评论内容质量很高，感谢你们的分享，通过自己的思考，自己有收获，同时也能帮助其他同学。
+
+也有很多同学基于自己的业务进行了思考和提出了一些疑问，这是非常好的学习方式，也是知行合一的一种行动方式，我也会尽量一一回复，帮助你解决一些实际的问题。
+
+再次感谢你对架构专栏的厚爱，让我们一起加油，一起成长！
+
+## 留言精选
+
+<img src="https://static001.geekbang.org/resource/image/74/48/745ef1a57eb5e7e29f15d783c36c3148.jpeg" alt="">
+
+华仔：做技术里面最擅长讲故事的，讲故事里面最擅长做技术的，说的就是你 ：）
+
+<img src="https://static001.geekbang.org/resource/image/94/2b/947c24b5e18e64afa4e7e79aa353482b.jpeg" alt="">
+
+华仔：说的这么好，除了赞同就是鼓掌了 ：）
+
+<img src="https://static001.geekbang.org/resource/image/c5/9f/c561f69db43f316d63463b992a7fb09f.jpeg" alt="">
+
+华仔：用马哲来思考架构设计，我表示这高度我要仰望一下 ：）
+
+<img src="https://static001.geekbang.org/resource/image/21/00/217a291744f3e296097800a4ef673400.jpeg" alt="">
+
+华仔：实现财富自由，迎娶白富美，当上CTO，走向人生巅峰，就靠你的第3句话了 ：）
+
+<img src="https://static001.geekbang.org/resource/image/b1/06/b10c254f93993d97cfcf2e3559f12006.jpeg" alt="">
+
+华仔：感谢，我要去查查这位大神，学习一下。
+
+<img src="https://static001.geekbang.org/resource/image/fc/ca/fc9cb35411676aa13ad74bfd4a0a25ca.jpeg" alt="">
+
+华仔：非常好的实践方法，我们在架构设计流程中会讲到，就是指设计“备选方案”。
+
+<img src="https://static001.geekbang.org/resource/image/a8/cd/a85aabbf5327e684c2ff47016d15c3cd.jpeg" alt="">
+
+华仔：其实我最开始构思的时候是想写一本架构师工作指南，包括技术、管理、沟通等，后来发现目标太宏伟，时间精力有限，最后决定还是聚焦技术，你说的内容非常对，架构师在设计的时候还要考虑团队人员和组织的复杂度和能力水平。
+
+最后，再次恭喜@每天都在找小黄车、@narry、@懒人闲思、@张玮(大圣)、@追寻云的痕迹、@曹铮、@合民，也感谢写下留言的每位同学，希望下期你也能入选！
+
+

极客时间专栏/从0开始学架构/特别放送/架构师必读书单 | “华仔，放学别走！” 第5期.md

@@ -0,0 +1,126 @@
+<audio id="audio" title="架构师必读书单 | “华仔，放学别走！” 第5期" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e6/94/e6c8af3ef992fba5bf77e63b46d22294.mp3"></audio>
+
+你好，我是华仔。
+
+在专栏更新的时候，很多同学留言希望我推荐一些书籍可以课后继续学习，正好我自己也是一个爱读书的人，最近7 ~ 8年，平均每年读书超过50本，因此今天就从我读过的书籍中选择一些让我印象非常深刻的推荐给你。我把这些书分为成长、技术和业务三个方面，因为架构师本身就是一个比较综合的职位，对综合技能要求很高，需要你从各方面提升自己。
+
+我推荐的书是<!-- [[[read_end]]] -->我从几百本中挑出来的，可以说是经典中的经典了，但这并不意味着只要看完这些书就够了，读书和技术提升是类似的，都是一个长期积累的过程，积累越多、收获越大。关于技术人员具体如何学习、如何提升，可以参考我之前在InfoQ上发表的文章[《佛系程序员的月薪五万指南》](https://mp.weixin.qq.com/s/N00rWLkkLjV7zQnzxBVKaA)。
+
+每本书我习惯用“**一句话推荐**”，虽然显得比较“简短”，但我认为推荐语太多会框住你对书的理解，也担心剧透太多会影响你的阅读体验。好书就像美酒一样，一定要自己品尝才能真正体会其中美妙的滋味。
+
+## 成长篇
+
+**《异类》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/15/08/153e66f751edf87a100fcb6d19503d08.jpg"><br />
+**一句话推荐**：颠覆你对成功的认知，例如：什么才是赢在起跑线？为何现在的富人都是大约生于1955年左右？
+
+**《随机漫步的傻瓜》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/ce/bc/ceea3ffd2c18155eb0262f2d383a43bc.jpg"><br />
+**一句话推荐**：只要看这一本书，你就能免受所有鸡汤的毒害！
+
+**《一万小时天才理论》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/06/d9/0664eb4491dd8ffce9df3484febb63d9.jpg"><br />
+**一句话推荐**：1万小时理论实践版，详细阐述了1万小时天才理论的3个关键点。
+
+**《情商》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/2b/38/2b6bee7b6e5411d8b88c5e069cbf4f38.jpg"><br />
+**一句话推荐**：如果你认为你的老板还不如你聪明，那你需要好好看看这本书。
+
+**《优秀到不能被忽视》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/07/38/07ba04ed662d191c65f57d9bc9319638.jpg"><br />
+**一句话推荐**：不管是工作还是爱好，要想成功的原则是什么？很简单，“做别人愿意买单的事情”！
+
+**《影响力大师》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/73/bc/739c1d6d41d864d8eef8b756b723f4bc.jpg"><br />
+**一句话推荐**：天天立flag，月月打自己的脸？不是你意志力不行，而是你方法不对，这本书可以给你一套完善、可操作的方法。（注：我以前读的版本叫《关键影响力》，新版改名叫《影响力大师》。）
+
+## 技术篇
+
+推荐技术书籍实际上是有一定局限性的，因为每个技术领域其实差异还是挺大的，就算都叫程序员，前端程序员、客户端程序员、后端程序员之间差异就很大；即使都是后端程序员，Linux开发和Windows开发所需要的技术也不一样。因此我提炼了一个通用的技术书籍学习路径，不同技术领域可以按照这个路径去拆解：
+
+<li>
+深度学习你的代码**运行环境**：例如Linux程序员一定要深入学习Linux和UNIX的操作系统，iOS程序员要深入学习iOS系统，前端程序员要深入学习浏览器原理，以此类推。
+</li>
+<li>
+深入学习你的**核心工具**：例如Java程序员的核心工具是Java，嵌入式程序员是C，而DBA就不是学编程语言，而是学MySQL或者Oracle了。
+</li>
+<li>
+深度学习领域**基础知识**：例如后端程序员的网络编程，前端程序员的动效知识，Android客户端程序员的渲染知识，以及所有程序员都要求的算法知识等。
+</li>
+<li>
+广泛学习技术领域的通用**成熟技术**：例如前端程序员要学的React和Vue，Java程序员要学的Netty、Spring，互联网后端程序员的标配MySQL、Redis等。
+</li>
+
+下面我以Linux后端Java程序员为例，给你推荐相关技术书籍。
+
+**《UNIX编程艺术》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/72/b1/72eaac751cfc7429f13152b46da00cb1.jpg"><br />
+**一句话推荐**：经典书籍，结合UNIX的历史来讲UNIX设计哲学，改变你对编程的认知和理解。
+
+**《UNIX网络编程（卷1）》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/29/3d/292b604b21fd8b1e98170d703ee68c3d.jpg"><br />
+**一句话推荐**：经典书籍，网络编程必读。书很厚，重点是前三部分，不需要一次全部读懂，先通读，后面经常参考并且加深理解。
+
+**《UNIX环境高级编程》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/70/d8/70d86369e581ecce05958ad53d8b2dd8.jpg"><br />
+**一句话推荐**：经典书籍，Linux/UNIX C/C++程序员必读，就算是Java、PHP、Python等程序员也要通读一遍，了解系统底层能力有助于理解编程语言的各种实现。
+
+**《Linux系统编程》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/80/85/807ffa04368053fb013045161c2aea85.jpg"><br />
+**一句话推荐**：和《UNIX环境高级编程》类似，Linux平台可以看这本。
+
+**《TCP/IP详解（卷1）》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/45/74/4548d0694d609f32f07d1846d7a98574.jpg"><br />
+**一句话推荐**：经典书籍，全面介绍TCP/IP协议栈各种协议，重点看TCP和IP部分。
+
+**《算法之美》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/51/d6/5185c70d95a3bb45b0c4b3d5255bbed6.jpg"><br />
+**一句话推荐**：讲算法非常有趣的一本书，告诉你如何将算法应用于**恋爱**、生活、工作！
+
+**《算法设计与应用》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/20/74/20ac796f4b216d710282bbbd40e2f674.jpg"><br />
+**一句话推荐**：将算法与实际应用结合起来，从应用引出算法然后进行算法推理，如果你数学很牛，可以挑战一下这本书；如果你数学很菜，那我更加推荐这本书，因为其中的算法原理和应用场景分析得清晰易懂。
+
+**《Java编程思想》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/2d/c8/2dcdb60aa1ead68ca4113fd0fff261c8.jpg"><br />
+**一句话推荐**：经典书籍，全面介绍Java编程，入门必备。
+
+**《深入理解Java虚拟机》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/31/39/3131cee1836a8214c3fdbc504af0df39.jpg"><br />
+**一句话推荐**：全面理解Java虚拟机，原理介绍得深入浅出，很少有技术书籍我会优先推荐国内作者，而这本是我大力推荐的。
+
+**《C++ Primer》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/55/f0/555133872490a50760f1be2c180b47f0.jpg"><br />
+**一句话推荐**：经典书籍，全面介绍C++编程。当年我看了很多C++书籍都不得要领，看了这本后豁然开朗。
+
+## 业务篇
+
+不管是普通程序员还是架构师，实践工作中都需要有一定的业务理解能力，而架构师的业务理解能力要求更高。理解业务一方面有利于更好地设计有针对性的架构或者方案，另外一方面也可以防止被产品经理坑 ：）
+
+**《增长黑客》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/73/e7/73864ab731a4e97380ba803971f6e2e7.jpg">
+
+**一句话推荐**：肖恩·埃利斯和摩根·布朗的这本书理论体系完整，既给出了很多实践技巧，又总结了很多经验和需要避开的陷阱。
+
+**《需求》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/5d/9f/5d88f7d24ac97cbbdc583bf594452a9f.jpg">
+
+**一句话推荐**：如何理解用户需求、如何满足用户需求、同样产品为何有的公司失败而有的公司取得了巨大成功？这本书让我茅塞顿开，建议技术同学都推荐这本书给你们的产品经理。
+
+**《淘宝十年产品事》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/9f/ed/9f765404dc98fc31f65ba1026166d0ed.jpg"><br />
+**一句话推荐**：这本书总结了淘宝10多年发展过程中产品遇到的各种坑和挑战，让你明白“罗马不是一天建成的”，产品也是逐步演化的（这也是我的“架构设计三原则”中的“演化原则”）。
+
+**《定位》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/9f/19/9f370416a58d2589cdbd12617bdca719.jpg"><br />
+**一句话推荐**：告诉你如何做业务战略规划，有些偏重理论，架构师需要学习，程序员可以先放一边。
+
+**《宝洁制胜战略》**<br />
+<img style="margin: 0 auto" src="https://static001.geekbang.org/resource/image/3f/ac/3fb1148d47fc09ab8c8227c09dad1bac.jpg"><br />
+**一句话推荐**：结合宝洁的经验，提出了一套完善的战略规划和落地方法，理论与实践兼备，架构师必备，拿着这套方法论，就可以PK你的老板了。
+
+最后我想说，收藏书单和囤书不是目的，更不能收获成长，只有像学习专栏那样坚持下来，坚持阅读、坚持记录、坚持分享，才能让你从书中品尝到最妙的美酒。
+
+编辑乱入：华仔推荐的图书现已上架“极客商城”，价格比其他电商平台更美丽哦～现在订购，请从“极客时间发现页”下滑进入“极客商城”，即可选购华仔推荐图书。
+
+

极客时间专栏/从0开始学架构/特别放送/架构师成长之路 | “华仔，放学别走！” 第4期.md

@@ -0,0 +1,190 @@
+<audio id="audio" title="架构师成长之路 | “华仔，放学别走！” 第4期" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/cd/e5/cd9541b98dbea4da55d0aad0bdb8ede5.mp3"></audio>
+
+你好，我是华仔。《从0开始学架构》专栏已经全部更新完毕，我在专栏里给你讲述了我的完整架构设计方法论，包括架构设计的概念、原则、步骤、技巧、模式等，这些内容是我融合多年来的学习、实践、思考总结得出来的精华。“王婆自夸”一下，专栏就相当于一部《九阳真经》，你按照武功秘籍的方法去修炼，自然能够比站在村口大树下打木人桩效率要高得多。然而要成为高手，光知道招式还远远不够，更重要的是内功和判断，能够一眼看出对手的弱点或者破绽，知道“什么时候用什么招式”“遇到什么对手用什么招式”更重要。
+
+以架构设计原则的“合适原则”为例，专栏讲述了架构设计要遵循“合适原则”，不要过度设计，这个点非常关键，能够避免架构设计的时候盲目超前设计。但是我们在具体架构设计的时候，到底什么是“合适”，专栏也无法给出一个明确的标准可以放之四海而皆准去套用，因为“合适”和很多因素有关：业务发展、团队规模、技术实力、领导的喜好等。此时到底什么是“合适”就依赖架构师的“内功”了，很有可能同一个团队，A架构师认为X方案是合适的，B架构师认为Y方案是合适的，原因就在于不同的架构师“内功”不一样。
+
+我认为，架构师的内功主要包含三部分：**判断力**、**执行力**、**创新力**，简单解释如下：
+
+**判断力**：能够准确判断系统的复杂度在哪里，就像武侠高手一样，能准确地看出对手的破绽和弱点。
+
+**执行力**：能够使用合适的方案解决复杂度问题，就像武侠高手一样，能选择合适的招式或者方法打败对手。
+
+**创新力**：能够创造新的解决方案解决复杂度问题，就像武侠世界里，小一些的创新是创新招式，而武学宗师能够创立新的武学或者心法，例如张三丰创立太极拳一样。
+
+因此，要成为一个优秀的架构师，就需要不断地提升自己这几方面的内功，而这三方面的能力主要来源于**经验**、**视野**、**思考**。
+
+**经验**：设计过的系统越多、系统越复杂，架构师的内功也就越强，不管是成功的架构，还是失败的架构，不管是踩坑的经验，还是填坑的经验，都将成为架构师内功的一部分。
+
+**视野**：掌握的知识和技能越多、越深，架构师的内功也就越强，他山之石可以攻玉，站在巨人的肩膀上会看的更高更远。
+
+**思考**：经验和视野都是外部输入，类似于我们吃的食物，但光吃还不行，还要消化，将其变为我们自己的营养，这就是思考的作用。思考能够将经验和视野中的模式、判断、选择、技巧等提炼出来为我所用，思考也能促使我们产生新的创意和灵感。
+
+结合上面的分析，从程序员到架构师的成长之路，总的指导原则是：积累经验，拓宽视野，深度思考。按照这个总的原则为指导，接下来我们看看从程序员到架构师的成长过程中，具体如何实践。
+
+我把程序员到架构师的技术成长之路分为几个典型的阶段：工程师 - 高级工程师 - 技术专家 - 初级架构师 - 中级架构师 - 高级架构师。虽然总的指导原则是一样的，但具体的实践方法有很大差别，如果在正确的阶段采取了错误的方法，可能会出现事倍功半的问题。
+
+## 工程师
+
+【阶段描述】<br />
+成为一个合格的工程师需要1 ~ 3年时间，其典型特征是“**在别人的指导下完成开发**”，这里的“别人”主要是“高级工程师”或者“技术专家”，通常情况下，高级工程师或者技术专家负责需求分析和讨论、方案设计，工程师负责编码实现，高级工程师或者技术专家会指导工程师进行编码实现。
+
+【成长指导】<br />
+工程师阶段是最原始的“**基础技能积累阶段**”，主要积累基础知识，包括编程语言、编程工具、各类系统的基本使用。以Java后端工程师为例，工程师阶段需要积累的经验和技能有：
+
+<li>
+Java的语法、基本数据结构的使用。
+</li>
+<li>
+Eclipse、IDEA、Maven、Linux命令行等各种工具。
+</li>
+<li>
+数据库CRUD操作、缓存的基本使用等。
+</li>
+<li>
+业务系统的基本流程。
+</li>
+
+工程师阶段最好的学习方法就是找**经典的书籍系统地学习**，而不要遇到一个问题到网上搜搜然后就解决了事。以Java为例，《Java编程思想》《Java核心技术》《TCP/IP协议》这类大部头，一定要完整地看一遍，即使里面很多内容当前工作暂时用不上。
+
+## 高级工程师
+
+【阶段描述】<br />
+成长为高级工程师需要2 ~ 5年时间，其典型特征是“**独立完成开发**”，包括需求分析、方案设计、编码实现，其中需求分析和方案设计已经包含了“判断”和“选择”，只是范围相对来说小一些，更多是在已有架构下进行设计。以Java后端工程师为例，高级工程师需要完成的工作包括：
+
+<li>
+MySQL数据库表如何设计，是设计成两个表还是三个表？
+</li>
+<li>
+是否要用缓存，缓存的Key和Value如何设计，缓存的更新策略是什么？
+</li>
+<li>
+产品提出的需求是否合理？是否有更好的方式来满足？
+</li>
+
+【成长指导】<br />
+从普通工程师成长为高级工程师，主要需要“**积累方案设计经验**”，简单来说就是业务当前用到的相关技术的设计经验。以Java后端高级工程师为例，包括：表设计经验、缓存设计经验、业务流程设计经验、接口设计经验等。当接到一个业务需求的时候，高级工程师能够组合这些设计经验，最终完成业务需求。
+
+高级工程师阶段相比工程师阶段，有两个典型的差异：
+
+<li>
+深度：如果说工程师是要求知道How，那高级工程师就要求知道Why了。例如Java的各种数据结构的实现原理，因为只有深入掌握了这些实现原理，才能对其优缺点和使用场景有深刻理解，这样在做具体方案设计的时候才能选择合适的数据结构。
+</li>
+<li>
+理论：理论就是前人总结出来的成熟的设计经验，例如数据库表设计的3个范式、面向对象的设计模式、SOLID设计原则、缓存设计理论（缓存穿透、缓存雪崩、缓存热点）等。
+</li>
+
+针对技术深度，我的建议还是系统地学习，包括看书和研究源码。例如，研究Java虚拟机可以看《深入理解Java虚拟机》、研究MySQL可以看《MySQL技术内幕：InnoDB存储引擎》、研究Memcache可以去看其源码。
+
+针对设计理论，由于涉及的点很多，没有一本书能够涵盖这么多的设计点，因此更多的是依靠自己去网上搜索资料学习。那我们怎么知道哪些地方会有设计理论呢？简单来说，就是假设每个设计环节都有设计理论，然后带着这种假设去搜索验证看看是否真的有很熟的设计理念。
+
+## 技术专家
+
+【阶段描述】<br />
+成长为技术专家需要4 ~ 8年时间，其典型的特征是“**某个领域的专家**”，通俗地讲，只要是这个领域的问题，技术专家都可以解决。例如：Java开发专家、PHP开发专家、Android开发专家、iOS开发专家、前端开发专家等。通常情况下，“领域”的范围不能太小，例如我们可以说“Java开发专家”，但不会说“Java多线程专家”或“Java JDBC专家”。
+
+技术专家与高级工程师的一个典型区别就是，高级工程师主要是在已有的架构框架下完成设计，而技术专家会根据需要修改、扩展、优化架构。例如，同样是Java开发，高级工程师关注的是如何优化MySQL的查询性能，而技术专家可能就会考虑引入Elasticsearch来完成搜索。
+
+【成长指导】<br />
+从高级工程师成长为技术专家，主要需要“**拓展技术宽度**”，因为一个“领域”必然会涉及众多的技术面。以Java后端开发为例，要成为一个Java开发专家，需要掌握Java多线程、JDBC、Java虚拟机、面向对象、设计模式、Netty、Elasticsearch、Memcache、Redis、MySQL等众多技术。常见的拓展技术宽度的方法有：
+
+<li>
+学习业界成熟的开源方案，例如，Java开发可以去学习Redis、Memcache、Netty等，Android开发可以去研究Retrofit、Fresco、OkHttp等。
+</li>
+<li>
+研究业界的经验分享，例如BAT、FANG等大公司的经验，可以通过参加技术大会等方式去近距离了解。
+</li>
+
+需要注意的是，拓展技术宽度并不意味着仅仅只是知道一个技术名词，而是要深入去理解每个技术的原理、优缺点、应用场景，否则就会成为传说中的“PPT技术专家”。例如，以Java开发为例，知道Netty是个高性能网络库是远远不够的，还需要学习Netty的原理，以及具体如何使用Netty来开发高性能系统。
+
+## 初级架构师
+
+【阶段描述】<br />
+成长为初级架构师需要5 ~ 10年时间，其典型特征就是能够“**独立完成一个系统的架构设计**”，可以是从0到1设计一个新系统，也可以是将架构从1.0重构到2.0。初级架构师负责的系统复杂度相对来说不高，例如后台管理系统、某个业务下的子系统、100万PV量级的网站等。
+
+初级架构师和技术专家的典型区别是：**架构师是基于完善的架构设计方法论的指导来进行架构设计，而技术专家更多的是基于经验进行架构设计**。简单来说，即使是同样一个方案，初级架构师能够清晰地阐述架构设计的理由和原因，而技术专家可能就是因为自己曾经这样做过，或者看到别人这样做过而选择设计方案。
+
+但在实践工作中，技术专家和初级架构师的区别并不很明显，事实上很多技术专家其实就承担了初级架构师的角色，因为在系统复杂度相对不高的情况下，架构设计的难度不高，用不同的备选方案最终都能够较好地完成系统设计。例如，设计一个日PV 100万的网站，MySQL + Memcache + Spring Boot可以很好地完成，MongoDB + Redis + Nginx + php-fpm也可以很好地完成，备选方案设计和选择并不太难，更多的是看团队熟悉哪个技术。
+
+【成长指导】<br />
+从技术专家成长为初级架构师，最主要的是形成自己的“**架构设计方法论**”，我的架构设计专栏其实就是讲述完整的架构设计方法论，包括架构设计目的、架构设计原则、架构设计步骤、架构设计模式等，类似的架构设计方法论还有《恰如其分的软件架构：风险驱动的设计方法》和《领域驱动设计》等。
+
+要形成自己的架构设计方法论，主要的手段有：
+
+<li>
+系统学习架构设计方法论，包括订阅专栏或者阅读书籍等。
+</li>
+<li>
+深入研究成熟开源系统的架构设计，这个手段在技术专家阶段也会用到，但关注点不一样，同样是研究开源系统，技术专家阶段聚焦于如何更好地应用开源项目；初级架构师阶段聚焦于学习其架构设计原理和思想，例如Kafka的文档中就有关于消息队列架构设计的分析和取舍。
+</li>
+<li>
+结合架构设计方法论，分析和总结自己团队甚至公司的各种系统的架构设计优缺点，尝试思考架构重构方案。如果在这个基础上真的能够推动架构重构，那就更好了，既能够实践自己的架构设计方法论，同时积累经验，又能够展现自己的技术实力，拿到结果。
+</li>
+
+## 中级架构师
+
+【阶段描述】<br />
+成长为中级架构师需要8年以上时间，其典型特征是“**能够完成复杂系统的架构设计**”，包含高性能、高可用、可扩展、海量存储等复杂系统，例如设计一个和Kafka性能匹敌的消息队列系统、将业务改造为异地多活、设计一个总共100人参与开发的业务系统等。
+
+中级架构师与初级架构师的典型区别在于系统复杂度的不同，中级架构师面对的系统复杂度要高于初级架构师。以开源项目为例，初级架构师可能引入某个开源项目就可以完成架构设计，而中级架构师可能发现其实没有哪个开源项目是合适的，而需要自己开发一个全新的项目，事实上很多开源项目就是这样诞生出来的。
+
+【成长指导】<br />
+从初级架构师成长为中级架构师，最关键的是“**技术深度和技术理论的积累**”，例如：
+
+<li>
+技术理论：CAP、BASE是异地多活的设计理论基础、Paxos是分布式一致性的基础算法、2PC、3PC是分布式事务的基础算法等。
+</li>
+<li>
+技术深度：Kafka用磁盘存储还能做到高效是因为磁盘顺序写；Disruptor高性能是结合CPU预读取机制、缓存行、无锁设计等基础技术；Storm的高效异或确认机制；Flink的分布式快照算法等。
+</li>
+
+很多同学对这点可能有疑问，这些技术理论和技术深度的事情不应该是高级工程师阶段或者技术专家阶段就应该积累的么？为何到了中级架构师阶段反而是成长的关键了呢？主要原因在于高级工程师或者技术专家阶段即使去学习这些技术，实际上也比较难理解透彻，更加难以有机会去应用，更多的时候只是了解有这个技术点而已；而到了中级架构师阶段，面对高复杂度的系统，很多时候就是几个关键技术细节决定整个架构设计的成败，或者某个设计方案理论上就是不可行的，如果不深刻理解理论和相关的关键技术点，很难设计优秀的架构。
+
+以我做过的异地多活设计方案为例，之前很早我就知道CAP理论了，但也仅仅只是知道几个概念而已。真正做异地多活的时候，开始的时候还是走了不少弯路，试图做一个完美的异地多活系统，最终发现这其实是不可能的，某天突然顿悟：其实CAP理论已经明确指出来了这点，但最初学习CAP理论的时候，很难有这样深刻的理解。
+
+## 高级架构师
+
+【阶段描述】<br />
+成长为高级架构师需要10年以上时间，其典型特征是“**创造新的架构模式**”，例如：
+
+<li>
+谷歌大数据论文，创造了分布式存储架构、分布式计算MapReduce架构、列式存储架构，开创了大数据时代。
+</li>
+<li>
+在有MapReduce分布式计算架构的背景下，Storm又创造了流式计算架构。
+</li>
+<li>
+在虚拟机很成熟的背景下，Docker创造了容器化的技术潮流。
+</li>
+
+高级架构师与中级架构师相比，典型区别在于“创造性”，高级架构师能够创造新的架构模式，开创新的技术潮流。
+
+【成长指导】<br />
+坦白地说，对于从中级架构师如何才能成长为高级架构师，我并没有太好的指导，一个原因是我自我评价目前顶多算个中级架构师；另外一个原因是一旦涉及“创造性”，其实和艺术就比较类似了，创造性实际上是很难学会的，也很难由老师教会，更多是天分，或者某种场景下灵感爆发。
+
+参考技术界几个创造性的架构案例，我总结出几个可能诞生创造性架构的背景条件：
+
+<li>
+足够复杂的业务场景：例如谷歌的大数据、阿里的双十一、Facebook的海量用户等，业务场景越复杂，给技术带来的挑战更大，更有可能产生创造性的技术突破。
+</li>
+<li>
+足够强大的技术团队：绝大部分创造性的架构都来源于大公司，或者知名的研究机构；没有技术实力支撑，想突破也是心有余而力不足。
+</li>
+<li>
+不满足于现状的态度：例如虚拟机很成熟但是资源占用太多，所以发明Docker；MapReduce难以做到实时运算，所以创造Storm流式运算。
+</li>
+<li>
+尊重技术价值的文化：创造性的东西往往需要投入大量的人力和时间，而且刚开始一般都不会很成熟，如果完全结果导向、KPI导向，创新技术很可能在萌芽阶段就被否定。
+</li>
+
+## 总结
+
+关于如何在专业领域内提升，有条著名的“10000小时定律”，简单来说要成为某个领域顶尖的专业人才，需要持续不断10000小时的练习，例如小提琴、足球、国际象棋、围棋等领域，无一例外都遵循这个定律。我认为技术人员成长也基本遵循这个定律，我在文章中试图提炼一条通用的成长路径供你参考，但其实最关键的还是技术人员对技术的热情以及持续不断地投入，包括学习、实践、思考、总结等。
+
+最后，你可以统计一下自己从头到尾认真读过的技术书籍数量、系统研究过的开源项目的数量，然后自我评估一下自己目前处于哪个层级，看看是否有什么发现？
+
+既然是特别放送，自然少不了送出福利。先向所有订阅专栏的同学送出我整理的“架构师技能图谱”，感兴趣的同学可以点击[这里](http://time.geekbang.org/column/article/13915)获取。另外，26～50期入选精选留言的用户是@feifei、@凡凡、@summer、@yungoo、@xuan、@climber、@鹅米豆发、@铃兰Neko、@ant、@herist、@kaola、@fiseasky、@无问。、@天天向上卡索、@kel、@但莫、@LouisLimTJ、@darrykinger.com、@小胖狗、@one day、@海滨、@wmg、@William、@商伯阳，恭喜这些同学获得价值68元的专栏阅码。
+
+在这里，我也向你推荐一下微博技术专家胡忠想的《从0开始学微服务》专栏，对微服务架构感兴趣的同学不要错过哦。
+
+[<img src="https://static001.geekbang.org/resource/image/e0/81/e0de04ee59db5c435301003c240e7d81.jpg" alt="" />](http://time.geekbang.org/column/intro/115?utm_term=zeusQ4QDH&amp;utm_source=app&amp;utm_medium=81article37&amp;utm_Campaign=115-presell&amp;utm_content=banner0823)

极客时间专栏/从0开始学架构/特别放送/第二季回归 | 照着做，你也能顺利晋升！.md

@@ -0,0 +1,28 @@
+
+你好，我是华仔。
+
+2018年，我在极客时间开设了《从0开始学架构》这门课。我和你分享了自己多年研究和实践积累得到的一套**完整的架构设计方法论**，来帮助你提升架构设计的能力。
+
+为什么架构设计能力这么重要呢？因为它是技术人员晋升到高级别必备的能力，所以后来我也在QCon等场合分享了架构师怎么成长等内容。不出意外，除了架构本身的能力提升，我还被问到了很多关于**职场晋升**的问题。常见的典型问题有下面这些：
+
+1. 我平时工作太忙了，没有时间专门提升自己，也不知道应该优先提升什么能力。由于平时准备就不充分，心里没底，所以就算有晋升机会，我也不敢申请，怕在大家面前丢脸，怎么办？
+1. 身边跟我差不多的、甚至不如我的同事都晋升了，而我还在原地踏步。我不知道晋升这个游戏到底要怎么玩，这背后是不是有所谓的“潜规则”？
+1. 我得到了领导和同事的一致认可，胸有成竹地去参加晋升答辩，却感觉像茶壶里煮饺子，有货倒不出。而且我的PPT做得像流水账或者大杂烩，讲PPT像在念课文，面对评委的问题经常大脑短路，怎么办？
+1. 我信心满满地完成了晋升答辩，评委却判定我还没达到要求。我很迷茫，不知道下一个级别的具体要求是什么，怎么做才能打动评委呢？
+
+这些问题让我回想起了自己这些年的工作经历。我在软件行业摸爬滚打了16年，先后服务过华为、UC、阿里巴巴、蚂蚁金服等公司。这些公司有个共同点，那就是都具备完善的晋升体系。
+
+在这些公司的“打怪升级”的过程中，你们问到的这些问题，其实我也都遇到过，很多团队成员也跟我咨询、甚至吐槽过。为此，我花了很多时间去研究和思考晋升，再加上有很多实践的机会，所以我逐步积累了比较丰富的晋升经验。
+
+这些年自己晋升、指导团队成员晋升以及担任晋升评委的经历，让我深刻地理解了为什么晋升会这么难，为什么这么多人都对晋升充满了疑问。
+
+因为从本质上说，晋升是一个系统工程，但是却从来没有人跟你系统地介绍过它，更不用说深入地阐述它。
+
+就算是成熟的大公司，它们虽然制定了相关规章、制度、流程，但大部分都只是晋升规则的说明，而且充斥了大量抽象和模糊的内容。这些文件对于指导员工晋升并没有太大作用，导致大部分人对晋升存在一知半解的模糊理解，甚至完全错误的理解。
+
+为了帮助你系统和深入地理解并实践晋升，我为你准备了一门新课，《大厂晋升指南》。整个课程是一套**完整的晋升方法论**，涵盖了晋升这项系统工程的各个领域。
+
+现在，课程已经上线了。我为你申请了老用户福利，一张15元专属优惠券，可与限时优惠叠加使用，到手仅需84元，建议尽早使用。
+
+点击下方图片即可进入新课程试读，期待与你在《大厂晋升指南》里继续交流！<br>
+[<img src="https://static001.geekbang.org/resource/image/41/21/4193f3e6eca109b7030b885f015fa521.jpg" alt="">](https://time.geekbang.org/column/intro/366?utm_term=zeusVW2TG&amp;utm_source=geektime-app&amp;utm_medium=geektime&amp;utm_campaign=100064501&amp;utm_content=diyijiwenzhang)

极客时间专栏/从0开始学架构/特别放送/致「从0开始学架构」专栏订阅用户.md

@@ -0,0 +1,18 @@
+<audio id="audio" title="致「从0开始学架构」专栏订阅用户" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/42/f5/427ecbd1d13963bb358541b5a59820f5.mp3"></audio>
+
+你好，我是华仔。在我的专栏结束后，**今天又有一个好消息想分享给你，而且这件事情离不开每位订阅专栏同学的支持。**
+
+事情的源起是「从0开始学架构」专栏发布时，我在InfoQ公众号文章的一条留言。
+
+<img src="https://static001.geekbang.org/resource/image/74/6b/740c2af41e4c203452e1cca3764c1b6b.jpg" alt="" />
+
+由于我一直有不定期捐助“免费午餐”的习惯，当时就想正好借此机会，完成一个小小的愿望：在专栏结束后，按照订阅人数，捐出同等数量的免费午餐。
+
+9月，在专栏结束后，有26000人订阅了我的专栏，而我也兑现了当初的承诺，捐出了26000份免费午餐，耒阳市导子镇上古小学（[微博](https://m.weibo.cn/u/6478785428?from=1089395010&amp;wm=9006_2001&amp;sourceType=weixin&amp;uid=2058877932)）的100个孩子可以放心吃上1年。
+
+<img src="https://static001.geekbang.org/resource/image/99/a8/99c5cf7ffbc1abb17a5393d4404f7aa8.jpeg" alt="" /><br />
+<img src="https://static001.geekbang.org/resource/image/91/e0/912ad45ddf78ca313ce1f3299041a6e0.jpg" alt="" />
+
+正如我当初立下的一个小小的flag：让技术既改变自己，也惠泽他人。通过专栏，我们一起学习进步，又一起完成100个孩子1年免费午餐的捐助，当初立下的flag算是完美达成。**我代表孩子们感谢订阅了专栏的你，也祝愿孩子们健康快乐成长，长大后成为优秀的架构师 ：）**
+
+