qq_37756660的博客

…系统是一个……的系统，是公司……战略的核心系统，承担着公司……的目标任务。系统主要功能包括……，使用者包括……。

倚天屠龙记》里有这么一段，赵敏和周芷若势同水火，非要拼个你死我活，结果张无忌来了后，几句话就让两个人情同姐妹。看的明教众人面面相觑，最后得出一个结论：能者无所不能。我认识的很多技术高手也常常给我这样一种感觉，他们不只是技术好，他们几乎无所不能。对业务的理解，对人际关系的把握，对未来发展的预见性，对事物本质一针见血的描述，常常使我既惊叹，又佩服。曾经我以为这些人是因为技术好所以样样精通，后来我猜想他们是因为样样精通所以技术好。软件开发是一个实践性很强的技术活动。

做技术开发同学的职业规划通常有两个方向：一个是持续做技术，成为技术专家、架构师；一个是转管理，带领技术团队做开发。开发团队需要管理者，那么开发出身的工程师做管理者也是顺理成章的事。过去十几年，很多优秀的工程师成功转为技术管理人员，成功的比例似乎比成长为技术专家的比例还要高一些。这也给了更多工程师转管理的信心，似乎技术转管理是一件相对比较容易的事。

我们在日常工作中，总要和很多人合作。有时候，我们需要依赖别人的工作结果，以作为我们工作的输入；有时候，我们的工作产出需要交付给别人，才能产生最终的价值。在这些合作过程中，可能会遇到各种问题。如何通过有效的沟通解决各种问题，这里给出一些建议，供你参考。

我工作这么多年来，经历过很多公司，参加过很多次技术会议，就我所见，几乎所有的技术会议都没有有意识地讨论过一个主题：这个会要解决的问题是什么？很多时候，会议一开始就讨论解决方案。有的会议上，产品经理上来就说我们需要一个什么样的功能，请技术部门给一个技术方案和工作量评估，至于这个功能用来解决什么问题，给用户或者公司带来什么价值，几乎很少说明。有的会议上，架构师上来就说我们打算推广一个什么样的技术，请相关技术团队配合，至于这个技术用来解决什么问题，给用户或者公司带来什么价值，也几乎很少说明。

这些年，我跟一些年轻的软件工程师朋友们交流，关于未来的职业发展，大家普遍都有憧憬和规划，要做架构师，要做技术总监，要做 CTO。对于如何实现自己的职业规划，也都信心满满：努力工作，好好学习，不断提升自己。但现实总是复杂的，日复一日的工作生活总能让人一次又一次地陷入迷茫。其原因之一就是对职业发展轨迹和自我能力进步的一般规律缺乏认识，导致做事找不到方向或是操之过急。

Hash 值是一个随机值，把一个随机值放到一个环上以后，可能是不均衡的，也就是说某两个服务器节点在环上的可能距离很近，而和其它的服务器距离很远，这个时候就会导致有些服务器的负载压力特别大，有些服务器的负载压力非常小。通过这种方式，Key 不变的情况下找到的总是相同的服务器。而且因为 MySQL 有主从复制的能力，事实上，在迁移的时候，只需要将这些 Schema 的从库配置到新服务器上，数据就开始复制了，等数据同步完成，再将新服务器的 Schema 设置为主服务器，就完成的集群的扩容。

在软件开发招聘中，“有多少年工作经验”是一个重要的招聘指标。但实际上，技术能力和工作年限并不是正相关的，特别是工作三五年以后，很多人的技术能力进步就几乎停滞了。但是招聘面试的时候，面试官是期待他有着和工作年限相匹配的技术能力的。如果一个人空有十几年工作经验，却没有相应的技术能力，那么这十几年的工作经验甚至可能会成为他的劣势，至少反映了他已经没有成长空间了。反而是工作年限不如他，但是技术能力和他相当的其他候选人更有优势，因为这个人可能还有进步的空间。

在我的职业生涯中，我经历过各种各样的技术创新，见识过各种技术狂热的风潮，也看过各种技术挫折，但从来没有一种技术能像区块链技术这样跌宕起伏，具有戏剧性，吸引了各色人等。区块链为什么能吸引这么多的关注？它到底能做什么？它的技术原理是什么？又为何如此曲折？让我们从区块链的起源——比特币说起。

当我们在说大数据技术的时候，说的可能是几种差别很大的技术。一种是大数据底层技术，指的就是各种大数据计算框架、存储系统、SQL 引擎等等，这些技术比较通用，经过十几年的优胜劣汰，主流的技术产品相对比较集中，主要就是上篇专栏讨论的 MapReduce、Spark、Hive、Flink 等技术产品。一种是大数据平台技术，Spark、Hive 这些大数据底层技术产品不像我们前面讨论过的分布式缓存、分布式消息队列，在处理用户请求的应用中，使用这些技术产品的 API 接口就可以了。

在开篇词讲到，任何新技术都不是凭空产生的，都是在既有技术的基础之上，进行了一些创新性的组合扩展，应用到一些合适的场景之中，然后爆发出来巨大的生产力。后面几篇我要讲的大数据技术，区块链技术都是如此。大数据技术其实是分布式技术在数据处理领域的创新性应用，本质和我们此前讲到的分布式技术思路一脉相承：用更多的计算机组成一个集群，提供更多的计算资源，从而满足更大的计算压力要求。前面我们讨论的各种分布式缓存、负载均衡、分布式存储等都是讲如何在高并发的访问压力下，利用更多的计算机满足用户的请求访问压力。

系统安全是一个老生常谈又容易被忽视的问题，往往只有在系统被攻击了，数据泄漏了，才会关注软件安全问题。互联网应用因为要向全球用户提供服务，在任何地方都可以访问互联网应用，任何恶意的用户可以在世界任何地方对互联网系统发起攻击，因此互联网系统又具有天然的脆弱性。在互联网各种安全问题中，最能引发话题，刺激大众神经的就是用户密码泄露。数据库被拖库，导致所有的数据泄露，这种系统安全问题涉及的因素可能有很多，大部分都和开发软件的程序员没有关系。

我们的 Web 程序每个星期都会发布一个新版本，但是程序要求 7*24 小时可用，也就是说，启动新版本程序替换老程序，进行程序升级的时候，程序还在对外提供服务，用户没有感觉到停机，我们是怎么做到的呢？应用程序升级必须要用新版本的程序包替代老版本的程序包，并重新启动程序，这段时间程序是不能对外提供服务的，用户请求一定会失败。但是阿里巴巴让这段时间的用户请求依然是成功的。打个比方，就是要在飞机飞行过程中更换发动机，还不能让乘客感觉到。

系统性能是互联网应用最核心的非功能性架构目标，系统因为高并发访问引起的首要问题就是性能问题：高并发访问的情况下，系统因为资源不足，处理每个请求的时间都会变慢，看起来就是性能变差。因此，性能优化是互联网架构师的核心职责之一，通常我们想到性能优化，首先想到的就是优化代码。事实上，一个系统是由很多方面组成的，所有这些方面都可以进行优化，就是我们接下来要讲的 7 层优化。进行性能优化的一个首要前提是，我们必须知道系统当前的性能状况，然后才能进行性能优化。而了解系统性能状况必须通过性能测试，我们先看下性能测试。

微服务和业务的关系是非常紧密的，仅仅用好微服务技术框架是无法成功实施微服务的。成功实施微服务最重要的是做好业务的模块化设计，模块之间要低耦合，高聚合，模块之间的依赖关系要清晰简单。只有这样的模块化设计，才能够构建出良好的微服务架构。如果系统本身就是一团遭，强行将它们拆分在不同的微服务里，只会使系统变得更加混乱。关于模块的设计，可参考第 19 篇文章，组件设计原则。

我们在使用搜索引擎的时候，搜索结果页面会展示搜索到的结果数目以及花费时间。比如用 Google 搜索中文“后端技术”这个词，会显示找到约 6.7 亿条结果，用时 0.45 秒。我们知道 Google 收录了全世界几乎所有的公开网页，这是一个非常庞大的数目，那么 Google 是如何做到在如此短的时间内完成了如此庞大的数据搜索呢？

在整个互联网系统架构中，承受着最大处理压力，最难以被伸缩的，就是数据存储部分。原因主要有两方面。一方面，数据存储需要使用硬盘，而硬盘的处理速度要比其他几种计算资源，比如 CPU、内存、网卡都要慢一些；另一方面，数据是公司最重要的资产，公司需要保证数据的高可用以及一致性，非功能性约束更多一些。因此数据存储通常都是互联网应用的瓶颈。在高并发的情况下，最容易出现性能问题的就是数据存储。目前用来改善数据存储能力的主要手段包括：数据库主从复制、数据库分片和 NoSQL 数据库。

负载均衡是互联网系统架构中必不可少的一个技术。通过负载均衡，可以将高并发的用户请求分发到多台应用服务器组成的一个服务器集群上，利用更多的服务器资源处理高并发下的计算压力。那么负载均衡是如何实现的，如何将不同的请求分发到不同的服务器上呢？早期，实现负载均衡需要使用专门的负载均衡硬件设备，这些硬件通常比较昂贵。随着互联网的普及，越来越多的企业需要部署自己的互联网应用系统，而这些专用的负载均衡硬件对他们来说成本太高，于是出现了各种通过软件实现负载均衡的技术方案。

上一篇文章中我们讨论过，使用缓存架构可以减少不必要的计算，快速响应用户请求。但是缓存只能改善系统的读操作性能，也就是在读取数据的时候，可以不从数据源中读取，而是通过缓存读取，以加速数据读取速度。但是对于写操作，缓存是无能为力的。虽然缓存的写入速度也很快，但是通常情况下，我们不能把用户提交的数据直接写入缓存中，因为缓存通常被认为是一种不可靠的存储。缓存通常无法保证数据的持久性和一致性等这些数据存储的基本要求，因此数据写操作还是需要写入到 RDBMS 或者 NoSQL 数据库中，但是数据库操作通常都比较慢。

上一篇我们讲到，互联网应用的主要挑战就是在高并发情况下，大量的用户请求到达应用系统服务器，造成了巨大的计算压力。互联网应用的核心解决思路就是采用分布式架构，提供更多的服务器，从而提供更多的计算资源，以应对高并发带来的计算压力及资源消耗。那么有没有办法减少到达服务器的并发请求压力呢？或者请求到达服务器后，有没有办法减少不必要的计算，降低服务器的计算资源消耗，尽快返回计算结果给用户呢？有，解决的核心就是缓存。

互联网应用以及云计算的普及，使得架构设计和软件技术的关注点从如何实现复杂的业务逻辑，转变为如何满足大量用户的高并发访问请求。一个简单的计算处理过程，如果一旦面对大量的用户访问，整个技术挑战就会变得完全不同，软件开发方法、技术团队组织、软件的过程管理都会完全不同。以新浪微博为例，新浪微博最开始只有两个工程师，一个前端，一个后端，两个人开发了一个星期就把新浪微博开发出来了。

今天是第二模块的最后一讲。在这一讲中，我们主要讲了软件的设计原理，在最后列了一个书单，这个书单里涉及到的书，可能会对学习设计模式有一些帮助。让我们整理一下，再接着学习下一个模块的内容。如果项目初始就对 Button 按钮进行这么复杂的设计，那么这么项目后期的维护成本也是相当之高。我们这个模块是讲设计的，这些设计原则都是用来解决需求变更的问题的。如果你为需求变更而进行了设计，但是预期中的需求变更却从来没有发生过，那么你的设计就属于设计过度；

工作的头一年，坐在我对面的同事负责开发一个公司统一的运维系统。他对这个系统经过谨慎的调研和认真的思考，花费了半年多的时间开发，终于开发完了。然后邀请各个部门的相关同事做发布评审，如果大家没什么意见就发布上线，全公司范围统一推广使用。结果在这个发布会上，几乎所有部门的同事都提出了不同的意见：虽然这个功能是我们需要的，但是那个特性却是不能接受的，我们以往不是这样的……最糟糕的是，不同部门的这个功能和那个特性又几乎不相同。最终讨论的结果是，这个系统不发布推广，需要重新设计。

软件的复杂度和它的规模成关系，一个复杂度为 100 的软件系统，如果能拆分成两个互不相关、同等规模的子系统，那么每个子系统的复杂度应该是 25，而不是 50。软件开发这个行业很久之前就形成了一个共识，应该将复杂的软件系统进行拆分，拆成多个更低复杂度的子系统，子系统还可以继续拆分成更小粒度的组件。也就是说，软件需要进行模块化、组件化设计。事实上，早在打孔纸带编程时代，程序员们就开始尝试进行软件的组件化设计。那些相对独立，可以被复用的程序被打在纸带卡片上，放在一个盒子里。

在专栏第 1 篇就讨论了为什么在高并发的情况下，程序会崩溃。主要原因是，在高并发的情况下，有大量用户请求需要程序计算处理，而目前的处理方式是，为每个用户请求分配一个线程，当程序内部因为访问数据库等原因造成线程阻塞时，线程无法释放去处理其他请求，这样就会造成请求堆积，不断消耗资源，最终导致程序崩溃。这是传统的 Web 应用程序运行期的线程特性。对于一个高并发的应用系统来说，总是同时有很多个用户请求到达系统的 Web 容器。

框架是对某一类架构方案可复用的设计与实现。所有的 Web 应用都需要监听 HTTP 端口，也需要处理请求参数，这些功能不应该在每个 Web 应用中都被重复开发，而是应该以通用组件的形式被复用。但并不是所有可被复用的组件都被称作框架，框架通常规定了一个软件的主体结构，可以支撑起软件的整体或者局部的架构形式。比如说，Tomcat 完成了 Web 应用请求响应的主体流程，我们只需要开发 Servlet，完成请求处理逻辑，构造响应对象就可以了，所以 Tomcat 是一个框架。

面试的时候，喜欢问一个问题：“你比较熟悉哪些设计模式？”得到的回答很多时候是“单例”和“工厂”。老实说，这个回答不能让人满意。因为在我看来，单例和工厂固然是两种经典的设计模式，但是，这些创建类的设计模式并不能代表设计模式的精髓。设计模式的精髓在于对面向对象编程特性之一——多态的灵活应用，而多态正是面向对象编程的本质所在。

工作期间，曾经负责开发一个统一缓存服务。这个服务要求能够根据远程配置中心的配置信息，在运行期动态更改缓存的配置，可能是将本地缓存更改为远程缓存，也可能是更改远程缓存服务器集群的 IP 地址列表，进而改变应用程序使用的缓存服务。这就要求缓存服务的客户端 SDK 必须支持运行期配置更新，而配置更新又会直接影响缓存数据的操作，于是就设计出这样一个缓存服务 Client 类。

工作期间，曾经接手过一个大数据 SQL 引擎的开发工作。接手的时候，这个项目已经完成了早期的技术验证和架构设计，能够处理较为简单的标准 SQL 语句。后续公司打算成立一个专门的小组，开发支持完整的标准 SQL 语法的大数据引擎，然后进一步将这个产品商业化。接手后打开项目一看，吓出一身冷汗，这个项目只有几个类组成，其中最大的一个类，负责 SQL 语法的处理，有近万行代码。代码中充斥着大量的 switch/case，if/else 代码，而且方法之间互相调用，各种全局变量传递。

我们都知道，面向对象编程语言有三大特性：封装、继承、多态。这几个特性也许可以很快就学会，但是如果想要用好，可能要花非常多的时间。通俗地说，接口（抽象类）的多个实现就是多态。多态可以让程序在编程时面向接口进行编程，在运行期绑定具体类，从而使得类之间不需要直接耦合，就可以关联组合，构成一个更强大的整体对外服务。绝大多数设计模式其实都是利用多态的特性玩的把戏，前面两篇学习的开闭原则和依赖倒置原则也是利用多态的特性。正是多态使得编程有时候像变魔术，如果能用好多态，可以说掌握了大多数的面向对象编程技巧。

在软件开发过程中，我们经常会使用各种编程框架。如果你使用的是 Java，那么你会比较熟悉 Spring、MyBatis 等。事实上，Tomcat、Jetty 这类 Web 容器也可以归类为框架。框架的一个特点是，当开发者使用框架开发一个应用程序时，无需在程序中调用框架的代码，就可以使用框架的功能特性。比如程序不需要调用 Spring 的代码，就可以使用 Spring 的依赖注入，MVC 这些特性，开发出低耦合、高内聚的应用代码。

在上篇文章讲到，软件设计应该为需求变更而设计，应该能够灵活、快速地满足需求变更的要求。优秀的程序员也应该欢迎需求变更，因为持续的需求变更意味着自己开发的软件保持活力，同时也意味着自己为需求变更而进行的设计有了用武之地，这样的话，技术和业务都进入了良性循环。但是需求变更就意味着原来开发的功能需要改变，也意味着程序需要改变。如果是通过修改程序代码实现需求变更，那么代码一定会在不断修改的过程中变得面目全非，这也意味着代码的腐坏。有没有办法不修改代码却能实现需求变更呢？

有人说，在软件开发中，优秀的程序员比糟糕的程序员的工作产出高 100 倍。这听起来有点夸张，实际上，可能更悲观一点，就我看来，有时候，后者的工作成果可能是负向的，也就是说，因为他的工作，项目会变得更加困难，代码变得更加晦涩，难以维护，工期因此推延，各种莫名其妙改来改去的 bug 一再出现，而且这种局面还会蔓延扩散，连那些本来还好的代码模块也逐渐腐坏变烂，最后项目难以为继，以失败告终。如果仅仅是看过程，糟糕的程序员和优秀的程序员之间，差别并没有那么明显。

在上一篇文章中，我们讨论了为什么要建模，以及建模的 4+1 视图模型，4+1 视图模型很好地向我们展示了如何对一个软件的不同方面用不同的模型图进行建模与设计，以完整描述一个软件的业务场景与技术实现。但是软件开发是有阶段性的，在不同的开发阶段用不同的模型图描述业务场景与设计思路，在不同阶段输出不同的设计文档，对于现实的开发更有实践意义。软件建模与设计过程可以拆分成需求分析、概要设计和详细设计三个阶段。UML 规范包含了十多种模型图，常用的有 7 种：类图、序列图、组件图、部署图、用例图、状态图和活动图。

我们开发的绝大多数软件都是用来解决现实问题的。通过计算机软件，可以用高效、自动化的方式去解决现实中低效的、手工的业务过程。因此软件开发的本质就是在计算机的虚拟空间中根据现实需求创建一个新世界。阿里的工程师在创造一个“500 平方公里”的交易市场，百度的工程师在创造一个“一万层楼”的图书馆，新浪微博的工程师在创造“两亿份报纸”，腾讯的工程师在创造“数 10 亿个聊天茶室和棋牌室”。现实世界纷繁复杂，庞大的软件系统也需要很多人合作，开发出众多的模块和代码。如何使软件系统准确反映现实世界的业务逻辑和需求？

我们回到小美同学的问题，Tomcat 启动的时候，启动的是 JVM 进程，这个进程首先是执行 JVM 的代码，而 JVM 会加载 Tomcat 的 class 执行，并分配一个主线程，这个主线程会从 main 函数开始执行。而我们开发的应用是一些 class，被 Tomcat 加载到这个 JVM 里执行，所以，即使这里有多个应用被加载，也只是加载了一些 class，我们的应用被加载进来以后，并没有增加 JVM 进程中的线程数，也就是 web 应用本身和线程是没有关系的。，这些线程也会被操作系统调度执行。

软件架构师必须站在一个很高的高度去审视自己软件的架构，去理解自己的工作在更宏大的背景中的位置和作用，才能构建出一个经得起时间考验的软件系统。这个高度既包括技术的高度和深度，也包括对软件编程这件事认知的程度，比如对软件编程的历史和未来的理解，以及对自己工作的价值和使命感的理解。计算机软件编程是个非常新兴的行业，程序员这一职业的出现不过半个多世纪，但是人类从事软件编程的探索却要久远得多，在计算机出现之前，甚至蒸汽机出现之前，人类就开始探索软件编程了。

做应用开发的同学常常觉得数据库由 DBA 运维，自己会写 SQL 就可以了，数据库原理不需要学习。其实即使是写 SQL 也需要了解数据库原理，比如我们都知道，SQL 的查询条件尽量包含索引字段，但是为什么呢？这样做有什么好处呢？你也许会说，使用索引进行查询速度快，但是为什么速度快呢？此外，我们在 Java 程序中访问数据库的时候，有两种提交 SQL 语句的方式，一种是通过 Statement 直接提交 SQL；另一种是先通过 PrepareStatement 预编译 SQL，然后设置可变参数再提交执行。

文件及硬盘管理是计算机操作系统的重要组成部分，让微软走上成功之路的正是微软最早推出的个人电脑 PC 操作系统，这个操作系统就叫 DOS，即 Disk Operating System，硬盘操作系统。我们每天使用电脑都离不开硬盘，硬盘既有大小的限制，通常大一点的硬盘也不过几 T，又有速度限制，快一点的硬盘也不过每秒几百 M。文件是存储在硬盘上的，文件的读写访问速度必然受到硬盘的物理限制，那么如何才能 1 分钟完成一个 100T 大文件的遍历呢？想要知道这个问题的答案，我们就必须知道文件系统的原理。

我们开发的面向普通用户的应用程序，目前看来几乎都是互联网应用程序，也就是说，用户操作的应用程序，不管是浏览器还是移动 App，核心请求都会通过互联网发送到后端的数据中心进行处理。这个数据中心可能是像微信这样的自己建设的、在多个地区部署的大规模机房，也可能是阿里云这样的云服务商提供的一个虚拟主机。但是不管这个数据中心的大小，应用程序都需要在运行期和数据中心交互。比如我们在淘宝的搜索框随便输入一个字符“a”，就会在屏幕上看到一大堆商品。那么我们的手机是如何通过互联网完成这一操作的？