mod

极客时间专栏/架构实战案例解析/概述篇/01 | 架构的本质：如何打造一个有序的系统？.md

@@ -0,0 +1,145 @@
+<audio id="audio" title="01 | 架构的本质：如何打造一个有序的系统？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/39/53/397d92d9df0fdc074c25e95196669d53.mp3"></audio>
+
+你好，我是王庆友，今天是专栏的第一讲，我想先和你聊聊架构的本质。
+
+我们知道，现在的软件系统越来越复杂，当然相应地，架构的作用也越来越明显。作为开发人员，我们每天都在和架构打交道，在这个过程中，对于架构也经常会产生各种各样的问题：
+
+- 什么是架构？架构都有哪些分类，分别解决什么问题呢？
+- 怎样才是一个好的架构设计？我怎么才能成长为一名优秀的架构师呢？
+
+这些问题涉及我们对架构的认识，也是学习和运用架构的开始。所以，今天，我们就来深入地分析架构的实质，让你能够透彻地理解它。
+
+作为专栏的第一讲，我希望先和你讨论架构中理念性的部分，就是所谓架构的道，这样可以指导你学习后续的实操层面的内容，也就是架构的术。
+
+接下来，我们就正式开始吧，先说下我对架构本质的理解。
+
+## 架构的本质
+
+物理学中有个很著名的“熵增定律”：一个封闭系统，都是从有序到无序，也就是它的熵（即混乱程度）会不断地增加，最终系统会彻底变得无序。
+
+这个理论放在软件系统的演化上，也是非常适用的。
+
+一方面，随着业务需求的增加，我们会往系统里不停地添加业务功能；另一方面，随着访问量的不断增加，我们会不断通过技术手段来加强系统非业务性功能。如果事先不做良好的设计，随着时间的推进，整个系统野蛮生长，就会逐渐碎片化，越来越无序，最终被推倒重来。
+
+不过，自然界中的生物可以通过和外界交互，主动进行新陈代谢，制造“负熵”，也就是降低混乱程度，来保证自身的有序性，继续生存。比如，植物通过光合作用，把光能、二氧化碳和水合成有机物，以此滋养自己，延续生命。对于软件系统，我们也可以主动地调整系统各个部分的关系，保证系统整体的有序性，来更好地适应不断增长的业务和技术变化。这种系统内部关系的调整就是通过架构实现的，所以，架构的本质就是：
+
+> 
+**通过合理的内部编排，保证系统高度有序，能够不断扩展，满足业务和技术的变化。**
+
+
+这里包含两层意思，我们具体展开说下：
+
+**首先，架构的出发点是业务和技术在不断复杂化，引起系统混乱，需要通过架构来保证有序**。我们知道架构这个词来源于建筑行业，那为什么建筑行业需要“架构”呢？
+
+搭一个草房子很简单，可以直接上手；盖一个2层楼房，稍微复杂一些，但在工匠的经验指导下，问题也不大；而盖一座高楼，复杂性就大不一样了，我们需要考虑内部结构、承重、采光、排水、防雷抗震等，这就需要专业人员事先做好整体的架构设计，并严格地按照设计来施工。
+
+这里，你可以看到，建筑里的架构不是天然就有的，而是因为建筑越来越复杂，我们需要通过架构来管理这种复杂性，避免建造过程的失控。
+
+软件系统也是如此，从简单的桌面应用发展到现在的大型互联网平台，这个过程中，系统规模越来越大，业务和技术也越来越复杂。我们同样需要通过架构设计，消化复杂性带来的混乱，使系统始终处于一个有序状态，能够应对现有和将来的需求变化。
+
+**其次，架构实现从无序到有序，是通过合理的内部编排实现的，基本的手段，就是“分”与“合”，先把系统打散，然后将它们重新组合，形成更合理的关系。**
+
+<img src="https://static001.geekbang.org/resource/image/3d/ae/3dd1ae4724e696a488210a75a8bce4ae.jpg" alt="">
+
+具体地说，**“分”就是把系统拆分为各个子系统、模块、组件**。拆分的时候，首先要解决每个部分的定位问题，然后根据定位，划分彼此的边界，最后实现合理的拆分，我们比较熟悉的微服务架构，就是一种典型的拆分做法。
+
+**“合”就是基于业务流程和技术手段，把各个组件有机整合在一起**。比如说在微服务架构中，拆分为具体微服务后，我们需要对这些服务进行归类和分层，有些属于底层基础服务，有些属于上层聚合服务，还要尽可能地实现服务的平台化，比如我们最近说的中台，这些都是合的思想体现。
+
+这个分与合的过程将系统的复杂性分解为两个层次：
+
+- 首先，各个子系统承担独立的职责，内部包含了自身的复杂性。子系统的复杂性对外部是透明的，外部不用关心。
+- 其次，子系统通过封装后，简化为职责明确的一个点，因此，我们只需要在合的过程中，解决各个点之间的依赖关系，这样就可以定义出系统整体。
+
+举个例子，我们都知道GoF的23个设计模式，在Builder模式中，它的主逻辑只需要给出各个部件的组装关系即可，它不关心创建某个具体部件的内部逻辑，这个可以交给工厂模式去实现。这里，Builder模式负责粗粒度的组装逻辑，它承担的是合的部分；工厂模式负责细粒度的构造逻辑，承担的是分的部分，大家各自管理自己的复杂性。
+
+**通过合理的“分”与“合”，系统不是回到了原点，而是把原先铁板一块的系统变成一个富有弹性的结构化系统。这样，系统的复杂性有效地分解了，系统的有序度大幅度地提升了。**
+
+当然，系统的复杂性是多方面的，有技术上和业务上的，架构也是一个体系，会有多种架构一起来应对这些复杂性挑战。那么接下来，我们就来具体看下。
+
+## 架构的分类
+
+按照不同的角度，架构可以有很多分类，但一般来说，主要分为**业务架构**、**应用架构**和**技术架构**。那么，这些架构分别为谁服务，解决什么问题，相互之间是什么关系呢？
+
+回答这些问题前，我们先来看下系统的落地过程。
+
+系统首先由人来开发，然后由机器来运行，人和机器共同参与一个系统的落地。
+
+<img src="https://static001.geekbang.org/resource/image/95/64/95790773cbc59bedbb01a07894e94f64.jpg" alt="">
+
+对于负责开发的人来说，比较头疼的是，业务太复杂，脑子想不清楚，即使当前勉强把业务逻辑转化为代码，系统后续的维护也是问题。因此，开发人员的要求是系统概念清晰，业务逻辑容易理解，可以直观地进行代码开发。
+
+对于负责运行的机器来说，比较头疼的是，外部请求并发量太大，导致机器扛不住，有的时候，硬件还会出问题。因此，它的要求是系统能够水平扩展，支持硬件容错，保证系统的高性能和高可用。
+
+这里，**开发的痛点主要由业务架构和应用架构来解决，机器的痛点主要由技术架构来解决。**
+
+为什么这么说呢？我们看下，这些架构具体都是做什么用的。
+
+简单来说，业务架构就是讲清楚核心业务的处理过程，定义各个业务模块的相互关系，它从概念层面帮助我们理解系统面临哪些问题以及如何处理；而应用架构就是讲清楚系统内部是怎么组织的，有哪些应用，相互间是怎么调用的，它从逻辑层面帮助我们理解系统内部是如何分工与协作的。
+
+技术架构就是讲清楚系统由哪些硬件、操作系统和中间件组成，它们是如何和我们开发的应用一起配合，应对各种异常情况，保持系统的稳定可用。所以，技术架构从物理层面帮助我们理解系统是如何构造的，以及如何解决稳定性的问题。
+
+这里你可以看到，业务架构、应用架构和技术架构，分别从概念、逻辑和物理层面定义一个系统。业务架构给出了业务模块的划分和依赖关系，这也大致决定了应用系统如何分工和协作，当然这不需要严格地一一对应，比如一个商品业务，可能对应3个应用，一个前台商品展示应用、一个后台商品管理应用，以及一个商品基础服务，但这不影响我们从逻辑上理解，一个业务场景，有哪些应用参与，并且它们是如何协作的。
+
+而技术架构呢，通过保障应用的稳定运行，最终保证业务不出问题。比如在大促的时候，多个应用可能会受大流量冲击，技术架构就要考虑怎么通过技术手段，保障相关的应用能够处理高并发，从而保证大促顺利进行。
+
+这里，我举个拍电影的例子，来帮助你更直观地理解这三种架构的关系：业务架构定义了这个电影的故事情节和场景安排；应用架构进一步定义有哪些角色，每个角色有哪些职责，并且在每个场景中，这些角色是如何互动的；技术架构最后确定这些角色由谁来表演，物理场景上是怎么布置的，以此保证整个拍摄能够顺利完成。
+
+最后，我想强调一下：系统是人的系统，架构首先是为人服务的。因此，业务概念清晰、应用分工合理、人好理解是第一位的。然后，我们再考虑技术选型的问题，保证系统非功能性目标的实现。**所以做架构设计时，一般是先考虑业务架构，再应用架构，最后是技术架构。**
+
+## 什么是好的架构？
+
+从上面的内容，我们不难看出，一个好的架构必须满足两方面挑战：业务复杂性和技术复杂性。
+
+### 1. 业务复杂性
+
+系统首先要满足当前的业务需求，在此基础上，还要满足将来的业务需求，因此系统要能不断地扩展变化，包括调整现有功能，以及增加新功能。
+
+而且，系统的功能变化不能影响现有业务，不要一修改，就牵一发动全身，到处出问题。因此，在架构设计上，要做到系统的柔性可扩展，能够根据业务变化做灵活的调整。
+
+此外，市场不等人，上新业务要快，之前花了半年上了个业务，这回再上个类似的新业务，需要短时间就能落地。因此，架构设计上，还要做到系统功能的可重用，这样才能通过快速复用，实现业务敏捷和创新。
+
+### 2. 技术复杂性
+
+要保证一个业务能正常运行，除了满足业务功能之外，还要保证这个系统稳定可用。
+
+一个复杂系统是由很多部分组成的，如应用程序、服务器、数据库、网络、中间件等，都可能会出问题。那怎么在出问题时，能够快速恢复系统或者让备用系统顶上去呢？
+
+还有流量问题，平时流量不大，少量机器就可以处理，但在大促的时候，大量流量进来，系统是不是能够通过简单地加机器方式就能支持呢？
+
+此外还有低成本的问题，系统能否做到，使用廉价设备而不是高大上的IOE设备，使用免费的开源组件而不是昂贵的商业套件，使用虚拟化技术而不是物理机，并且在流量低谷和高峰的不同时期，让系统能够弹性缩容和扩容呢？
+
+这些都属于技术性的挑战，解决的是系统的非业务性功能，也都是架构设计要支持的。
+
+**因此，一个好的架构设计既要满足业务的可扩展、可复用；也要满足系统的高可用、高性能和可伸缩，并尽量采用低成本的方式落地。所以，对架构设计来说，技术和业务两手都要抓，两手都要硬。**
+
+那么，一个优秀的架构师需要具备什么样的能力，才能设计一个好的架构呢？
+
+## 什么是好的架构师？
+
+一个优秀的架构师，应具备很强的综合能力，要内外兼修，“下得厨房，上得厅堂”，下面我来通过典型的架构方式，来介绍一名优秀架构师应该具备的能力：
+
+<img src="https://static001.geekbang.org/resource/image/a1/9c/a177795d73884d912c4a5ae7fcea7e9c.jpg" alt="">
+
+一个驾校教练，必定开车技术好；一个游泳教练，必定游泳水平好，因为这些都是实践性很强的工作。架构师也是一样，TA必定是一个**出色的程序员**，写的一手好代码。
+
+在此基础上，**架构师要有技术的广度（多领域知识）和深度（技术前瞻）**。对主流公司的系统设计非常了解，知道优劣长短，碰到实际问题，很快就能提供多种方案供评估。
+
+此外，架构师还需要有**思维的高度，具备抽象思维能力**。抽象思维是架构师最重要的能力，架构师要善于把实物概念化并归类。比如，面对一个大型的B2C网站，能够迅速抽象为采购-&gt;运营-&gt;前台搜索-&gt;下单-&gt;履单这几大模块，对系统分而治之。
+
+架构师还需要有**思维的深度，能够透过问题看本质**。透过问题看本质是由事物的表象到实质，往深层次挖掘。比如，看到一段Java代码，知道它在JVM（Java Virtual Machine，Java虚拟机）中如何执行；一个跨网络调用，知道数据是如何通过各种介质（比如网卡端口）到达目标位置。透过问题看本质，可以使架构师能够敏锐地发现底层的真实情况，以端到端闭环的方式去思考问题，能够识别系统的短板并解决它。
+
+还有很重要的一点，能落地的架构才是好架构，所以架构师还需要具备**良好的沟通能力（感性）**，能确保各方对架构达成共识，愿意采取一致的行动；而**良好的平衡取舍能力（理性）**，可以确保架构在现有资源约束下是最合理的，能让理想最终照进现实。
+
+## 总结
+
+我今天和你分享了架构的本质，架构的终极目标是保证系统的有序，通过拆分和整合，使系统具有柔性，能够进化，从而可以满足现有的和将来的各种变化。
+
+如果你能深入地理解架构的这些本质和手段，就可以不用照搬某某大厂的方案了，而是能够根据实际情况，以最合理的方式来解决系统面临的问题。
+
+这里呢，我也分享了架构的三种典型分类，包括它们各自的定位和相互关系，相信你现在对架构整体有了一个简明的框架，知道架构设计都要做哪些事情了。
+
+最后，我还为你提供了高标准的架构师能力模型，这样，你能比较清楚自己的努力方向是什么，这些要求很高，但你也不要有任何的畏难情绪，你可以在架构实践中，逐步地往这个目标上靠近，通过本专栏后续的学习，相信你也可以更快地达到这个目标。
+
+**最后，给你留一道思考题：**除了本文提到的三种架构，你还知道有哪些架构分类，它们分别做什么用？
+
+我是王庆友，欢迎在留言区和我互动，我会第一时间给你反馈。如果这节课对你有帮助，也欢迎你把它分享给你的朋友。感谢阅读，我们下期再见。

极客时间专栏/架构实战案例解析/概述篇/开篇词 | 想吃透架构？你得看看真实、接地气的架构案例.md

@@ -0,0 +1,84 @@
+<audio id="audio" title="开篇词 | 想吃透架构？你得看看真实、接地气的架构案例" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/36/39/3671dd3b09dc9e0132487c2fa1558939.mp3"></audio>
+
+你好，我是王庆友，前1号店首席架构师，很高兴能在这里和你一起聊聊架构。
+
+架构的内容，相信你也看过很多了，博客、书籍、技术大会等等，都会有大量架构方面的分享。但一方面，这些内容比较碎片化，比如这一次讲的是技术的高并发处理，下一次讲的是老业务的改造。表面上看，你脑子里塞得满满的，但实际上，你很难循序渐进、系统地去学习架构。
+
+另一方面，这些内容大多比较含糊，看似说的要点很全，但缺乏关键的实现细节，这样的话，说的和做的联系不起来，结果就是你可能理解起来都有困难，更不用说在实际工作中落地了。因此，我想了想，要能为你提供全新的架构学习体验，那就是让理论和实战结合起来，理论讲透彻，实战提供大量接地气的案例，让你能够知行合一地学架构。
+
+我先简单介绍下自己吧，我从事软件开发已有二十年，架构设计也超过十年了，所以也经历了软件发展的各个阶段。
+
+一开始呢，我从事的是企业级软件开发，后来转到了大型互联网电商平台，最近我奋战在新零售领域，帮助传统的大型连锁餐饮企业搭建O2O平台，打通他们的线上和线下系统。
+
+从1号店开始，我负责了许多大项目的架构设计，积累了很多架构方面的经验。我是一个爱琢磨的人，喜欢总结做过的东西，形成一个体系化的认知。因此，在架构这个话题上，我有很多东西想和你分享。我希望，这些总结过的经验，可以帮你在成为架构师的道路上，少走一些弯路，也希望通过这个专栏能够抛砖引玉，和你一起讨论，一起成长。
+
+## 为什么开发人员要学习架构？
+
+这其实可以从系统和个人发展这两方面来看。
+
+### 一、无架构，不系统
+
+现在的软件系统规模越来越大，业务上和技术上都非常地复杂，大一点的互联网公司，技术人员都有几千号人。那么，如何开发这么复杂的系统？如何有效地组织他们的工作呢？
+
+在这里，一个好的架构设计无疑是至关重要的，无论你是有一定经验的开发人员，还是已经开始从事系统设计的架构师，深入学习和理解架构都是必不可少的，掌握好架构设计，可以让你轻松应对技术和业务的挑战。但是很多技术人员，由于个人项目经验有限，又缺乏很好的学习途径，对架构设计一知半解。在实际工作中，不能把握好架构设计的度，要么设计不足，要么过度设计，导致系统变来变去，严重影响开发效率和质量。
+
+### 二、拓展你的职业发展空间
+
+此外，对于技术人员来说，公司通常会提供两个职业发展通道供你选择：管理路线和技术路线。
+
+现实中，大部分同学应该都是走技术路线的，很多程序员的职业发展目标，也都是想要成为一名优秀的架构师。这不仅仅意味着更优渥的薪水和更持久的职业生涯，更因为在架构师这个舞台上，你可以凭借个人出色的架构能力，为项目的落地发挥巨大的作用，你会有更大的成就感。
+
+所以说，无论从软件发展的趋势，还是从个人职业发展方向上考虑，你都应该拥抱架构，主动学习，尽快成长为一个能力全面的架构师。
+
+## 如何学习架构？
+
+但是，成为一名优秀的架构师，却不是一件容易的事情，你需要克服很多挑战。
+
+- 首先，你需要跳出当前的小模块，站在系统整体的角度来考虑问题。
+- 其次，你不仅要从技术的角度考虑问题，也要学会从业务的角度来考虑问题，深入理解系统的挑战在哪里，不要在错误的地方发力。
+- 最后，你需要做好各方面的平衡，能在现有的各项资源约束下，寻求一个最优解。
+
+而这些，无疑都是非常考验人，也非常锻炼人的，需要你能够快速成长起来。如果你在走向架构师这条路上，完全靠自己摸索，找不到正确的方向，不断地犯错，你很可能会半途而废。
+
+那么，如何找到一个好的学习方式呢？
+
+我们知道，一门新的语言，有很多书籍教你如何从入门到精通；一个新的开源框架，也有全面的资料教你如何深入掌握。但**在架构学习这方面，并没有十分系统的理论指导，教你如何一步步进阶。**
+
+有时候，一些架构的术语和概念甚至都没统一，需要靠你自己去分辨。有时候，你可以从各种渠道找到一些项目的架构介绍，但不知是作者出于保密的目的，还是自己也没有深度参与项目，内容往往避实就虚，缺乏具体的东西。这样的架构介绍，参考性就很有限，你看过了，也就忘了，就像是中国的山水画，写意不写实，内行可以看门道，外行只能看热闹，无助于你实际能力的提升。
+
+**此外，架构设计的实践性很强**，如果公司的业务比较简单，对架构设计的要求不高，你就未必有很好的实践机会；如果你只是抽象地了解了一些架构原则，不去具体地实践它，那么你很难去学透架构，让它变成自己的能力。
+
+而在设计这个专栏的时候，我就有针对性地考虑到了这些问题，并给出了解决方案：
+
+- 首先，我不会在这里罗列所有架构相关的知识点，而是选择实践中最有用的部分，形成一个精简的体系，让你可以快速掌握架构的核心内容，抓住学习的重点。
+- **此外，本专栏的核心内容全部来自于本人实际项目的总结**。我会基于这些实战后的思考，和你深入分享我的经验和看法，让你能够透过现象看本质，对架构的认知快速到位。我想说的是，这将会是一个有态度的专栏，而不是架构知识的搬运工。
+- **更为重要的是，每讲课程，我会根据不同的架构原则，给你提供很多完整且非常接地气的实际案例**。比如说，通过1号店App服务端架构改造的案例，你将会深入地理解系统从单体架构到分布式，再到服务化演变的背后原因；通过1号店订单水平分库的案例，你将会了解大型互联网公司是如何解决单个数据库的性能和容量瓶颈的。这些案例都很典型，不但让你能够理论结合实践，深入理解和运用各种架构原则，而且在很多情况下，你甚至可以直接参考它们，在公司落地类似的架构改造。
+
+这个专栏，它有深度、有细节、实战性强。希望通过这个专栏，能让你对架构形成一个清晰的认知框架，并对各个架构要点形成自己的理解，同时，通过结合着大量实际案例的学习，希望最终你可以把这些知识变成实际的能力。
+
+## 我是如何规划这个课程的？
+
+首先，我会和你分享架构的本质，让你对架构形成一个体系化的认知。
+
+接下来，我将整体内容划分为**业务架构**和**技术架构**两大部分，先理论后案例，带你深入理解每种架构要解决的问题，以及如何解决。
+
+- **业务架构篇**：重点针对系统的扩展性和复用性两大目标展开。首先，我会介绍这两大目标的内涵和实现手段，让你明白如何通过业务的拆分和组合，搭建一个柔性可变的系统；然后，每部分都有三个实际案例，让你理解如何以服务化和平台化的方式升级改造系统，最终实现扩展性和复用性的目标。
+- **技术架构篇**：重点针对系统高可用和高性能/可伸缩的目标展开。首先，我会介绍实现这些目标的策略和架构原则，比如说，高可用的策略有避免事故、降低影响、快速恢复等，高可用的架构原则有无单点、可监控、水平扩展等，这样你可以总体了解，实现这些目标都有哪些手段；然后，每个目标都有3个实际案例，让你理解如何在项目中，灵活应用这些策略和原则。
+
+最后，我还会通过一篇架构总结，汇总架构原则，以及它们的适用场景，并就如何成长为优秀的架构师，为你提供一个可行的方向指导。
+
+## 写在最后
+
+那么在最后，我想说的是，架构对我们的工作是如此的重要，如果你想深入学习架构，除了有好的学习方法，你一定还要多思考，多交流，多实践。
+
+在课程设计中，我在每一节课后都留了思考题，希望你能够结合每篇文章的知识点，给出自己的思考。
+
+**这次当然也不例外，你可以给我留言，说说你对学习架构都有哪些困惑。**
+
+另外，你也要大胆地抛出问题，我一定会尽我所能及时给你反馈。很多问题都是共性的，我们一起讨论和解决，成长一定会更快。
+
+书上学来终觉浅，梅花香自苦寒来。好的指导方法加上你自身的努力实践，相信你的架构之路会越走越顺，越走越快。
+
+希望这个专栏，能够帮你开启架构师的进阶之路，在接下来的两个月里，让我们在架构之路上一起成长吧。
+
+我是王庆友，欢迎你把这个课程分享给你的朋友，我们一起学架构。感谢你的阅读，我们第一讲再见。