标签：感悟 需求 功能性 一个 十年 简单 架构 我们

十年架构感悟

蔡超 大家好，我是汇量科技的蔡超，也是 QCon 的老朋友了。 以前我会给大家分享一些具体的技术，例如微服务，甚至我会带上笔记本跟大家一起写写代码、调调程序。这次不一样，我会给大家分享一些软性的内容，分享一下我做架构这十年来的感悟。

1.“提出问题”难于“解决问题”

跟大家分享的第一个感悟是：“提出问题”难于“解决问题”。包括我在内，工程师们最大的一个特点就是善于解决问题，因为我们通常都是从问题解决者的角度来进行工作的。但是，我们很少会主动提出一些问题，主动从用户的场景出发去提出问题、提出需求。 很多时候，公司里的一些矛盾就来自于工程师和产品经理之间，比如我们常常会说产品经理不懂技术，需求提得不够专业。但我们作为工程师也可以想一下，我们是不是应该把自己的位置再往前挪一点，去看看用户到底有哪些困惑，然后提出一个合理的需求去解决它；或者我们自己去体验一下用户的场景，然后提出一个全新的问题并解决它。 简而言之，我们不要仅仅去做一个解决问题的人，也要做一个提出问题的人，主动去思考什么样的问题、需求，能让我们的业务更加先进。 很多时候，我们会觉得设计一个架构、写一个程序去解决问题是一件很难的事情，当然这也是一个很棒的工作。但如果你静下心来去尝试提出一些问题，改进一些用户的需求，你会发现，这是一件更难的事情，至少对我来讲是如此。 当然，这样的感觉不仅仅是我有，很多伟大的科学家也会有这样的困惑和感悟。 “The mere formulation of a problem is far more essential than its solution, which may be merely a matter of mathematical or experimental skills. To raise new questions, new possibilities, to regard old problems from a new angle requires creative imagination and marks real advances in science.” 这是爱因斯坦说过的一段话，大致意思是：我们解决一个问题的时候，常常只需要用到一些数学以及实验的能力就可以了，但提出一个新的问题，以一种新的角度去看待旧的问题，是需要用到我们的创造力才能够做到的，而这恰恰是真正推动科学进步的一部分。 不仅仅是爱因斯坦，软件大师 Frederick P. Brooks Jr.，《人月神话》的作者，在他最新一本讲设计原理的书《The Design of Design（设计原本）》里也谈到，“The hardest part of design is deciding what to design”，大概意思就是，设计最难的部分就是去决定我们要设计什么。

2. 决定“不要什么”比“要做什么”更难

跟大家分享的第二个感悟是：决定“不要什么”比“要做什么”更难。也许因为人性的本质是贪婪的，所以我们在做项目或架构的时候，常常是什么都想要，什么需求都往里放，对于非功能性需求就更是这样了。 我们去看一个架构设计说明书，往往会看到它在开头提到高的可用性、高的性能、高的扩展性、高的可维护性……几乎所有的架构设计书都是这样，这些非功能性需求仿佛成了一个公共的列表，所有的架构都要满足这些需求。当然，功能性需求更是不用说，产品经理会一个不拉地往里面塞。 我们回过头来仔细想想什么是架构。其实在很多层面上，架构是一种 tradeoff，一种权衡和平衡。作为一个架构师，你才最应该是那个说不的人。 在现实中，有很多东西是不可兼得的。比如产品是尽早发布，还是把所有功能都加上，发布一个完美的产品；再比如一致性和性能之间的 balance，我们是选择强一致性，还是选择性能等等。所有架构师都非常熟悉的 CAP 原则，其实本质上就是一个关于 balance 的准则。 因此，作为架构师，我非常推荐大家在做架构设计的一开始，就去确立一些做事的原则。比如数据一致性优先级最高，再比如尽早发布基础功能版本的优先级大于延迟发布完善功能产品等。当出现矛盾的时候，我们就可以利用这些原则来进行取舍。 这些原则是非常重要的，它们能够指导我们在做架构的时候做出正确的取舍，而不会随着工作的推进而迷失。 “Deciding what not to do is as important as deciding what to do.” 这是引自乔布斯的一句话，意思是决定不做什么和决定做什么同样重要。他在取舍方面一直做得非常棒。 可能大家都知道，由于和董事会的关系，乔布斯在 Apple 2 发布一段时间后，就被逐出了苹果。之后他去创办了自己的事业，NeXT，也非常成功。1997 年的时候，苹果收购 NeXT，乔布斯以顾问的形式回到苹果，却发现苹果有很多问题。当然，那个时候，苹果之所以请他回来做临时 CEO，也是因为意识到自身出现了很多问题。 乔布斯意识到苹果最大的问题在于它的产品线非常多，非常的繁杂，他就在白板上画了一个象限图，四个维度分别是 Desktop、Portable、Pro 和 Consumer，并要求苹果在每个象限里面只做一个产品，然后把这个产品做到极致。 “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully.I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.” 这就是乔布斯非常著名的谈专注的那段话，大概意思是，人们认为专注意味着对你需要专注的事情说 Yes。但并非如此，专注意味着你要对其他 100 个好主意说 No，你必须谨慎选择。相比已经完成的工作，他对那些没有完成的工作一样感到自豪。创新就是对 1000 件事情说 No。

3. 非功能性需求决定架构

跟大家分享的第三个感悟是：非功能性需求决定架构。在很多人心目中，做架构的第一步是收集需求，把各种需求都收集上，这个架构的目的就是要满足这些功能性需求的，毕竟最终产品是要为用户服务的。 事实并非如此，一个好的架构，其实是由非功能性需求决定的，而不是由功能性需求决定的。你会发现，一个功能可以有无数的架构方案来实现，但你为什么最终选择了某个方案，其实是由非功能性需求来进行筛选的。 大家非常清楚什么是非功能性需求，包括性能、伸缩性、可扩展性、可维护性等，甚至还包括了你的团队结构，你团队的技术水平，你对发布周期的要求等等，通过所有这些需求来筛选可使用的方案，最终找到一个合适的架构。 所以，非功能性需求是非常重要的，甚至可以说是在你的架构设计中起到决定性因素的。架构设计完之后，少一个功能性需求，我们很容易就能看出来，未来也可以加上去，它对你的架构不会有本质上的影响。但如果我们忽略的是某一种非功能性需求，那在未来这可以说是一种灾难性的麻烦，很有可能你就需要重写了。比如你架构中的数据一致性问题无法解决，或者在设计的时候没有充分考虑性能问题，这样，所有的功能性的实现其实都没有意义。基本就是 Refactor 了，甚至不应该叫 Refactor，要叫 Recreate 或者 Rewrite，等于你要完全重写整个架构。 实际上在架构领域，大家对这点也是有共识的。比如下图中这个 Micro-Kernel 的架构模式来自《面向模式的软件架构》的第一卷，它一大特点就是有比较好的可扩展性，同时通过 Plugin 之间的隔离，能够提高系统的可用性。 《面向模式的软件架构》这套书多年来一直是架构师的必读经典，书中很多架构都是从非功能性需求的角度展开去讲的，如果你想成为架构师，那就非常推荐给你去看。

4.“简单”并不容易

跟大家分享的第四个感悟是：“简单”并不容易。很多架构师都会提到保持简单，keep the simple，但很多时候我们会混淆简单和容易，简单是 simple，容易是 easy，我们是 keep it easy，而不是 keep it simple。 正如乔布斯所说，简单有时候要比复杂更难，需要你对问题、事物的研究非常地深入，你才能找到真正简单的方法。简单其实是蕴含着一种巧妙在其中的。例如我们熟知的布隆过滤器，是一个十分简单的高效重复数据过滤算法，它就非常巧妙地解决了一个问题。 如果你想把一个事情做简单，你需要做很多深入的工作，比如对于架构的简化，很大程度上来自于我们对于技术、开发过程，以及不同业务场景的深入理解，而不仅仅是这个架构写起来好不好写。 举个例子，我们来回顾一下软件生命周期中各个阶段的成本消耗占比。 可以看到，在整个软件生命周期中，成本消耗最高的并不是设计、编码这些阶段，而是维护阶段。也就是说，如果你让维护变得简单，这会是最有性价比的。 我之前在一家国际公司工作过，主要是为移动运营商设计一个移动设备管理系统，运营商可以通过这个系统实现移动设备的自动注册，固件和软件的同步更新等。当时的移动设备还是摩托罗拉、爱立信之类早期智能手机的时代，打开手机会看到移动菜单或联通菜单，移动运营商就通过这些菜单跟你同步更新，也会对你的系统固件进行升级。这些工作是根据一些管理系统与移动设备之间预定义的协议来完成的，比如 SyncML。而电信专家们会根据业务场景及需求不断调整和新增这些交互协议。 刚开始设计系统的时候，我们也想着 keep it simple，就采用了一种看似简单的实现方式，团队里的软件工程师拿到电信专家设计好的协议后，把协议翻译成对应的程序语言，每一种协议对应一个程序语言。这时候每个程序语言都是一个插件，扩展也很容易，把这个语言实现的 Plugin 插到系统中，或者 Update 一个 Plugin，就可以支持一种新功能了。 这么看你可能觉得还行，反正也是插件结构，看起来也相当简单、直接，于是照着这个设计我们实现了一个系统：任何一个新业务过来，先由电信专家设计协议，再由工程师把协议转换为代码，然后将这个代码写成一个 Server 插件部署到 Server 端，这个协议就被支持了。 但很快，我们就发现事情没那么简单，这套系统的维护成本高到令人发指。为什么？原因其实可以用 Martin Fowler 的一句话来解释： “I believe that the hardest part of software projects, the most common source of project failure, is communication with the customers and users of that software.” 沟通往往是导致软件项目失败的主要问题，的确是这样。这个系统最大的问题是在上线后的运行维护阶段，电信专家和工程师之间会不断地就新的协议修改和增加进行持续的沟通，但是他们之间的领域知识和词汇都有很大的差别，对彼此专业领域的理解有限，结果就大大影响沟通的效率。这期间系统修改每次都十分艰难，不仅协议更新上线时间慢，而且很多问题由于工程师对于电信协议理解程度有限，都要在开发完成，实际使用后才能被电信专家发现。导致了很多的交换和反复，也造成了很多客户的抱怨。 所以，这个系统只是表面上看起来简单，最终整个过程演变得没那么简单。 那什么才是真正的简单？发现上面提到的这些问题，以及背后的原因是沟通后，我们开始重新思考解决的方法。后来我们和电信专家一起设计了一种协议设计语言 DSL，Domain Specific Language。DSL 是用电信专家熟悉的词汇来进行描述的，我们还提供了可视化工具，让电信专家能非常轻松容易地使用。然后这个协议会通过一个类似于编辑器的工具，将电信专家定义好的协议模型转换为内存中的 Java 结构，在线上进行运行。这样整个项目的运行和维护就变得更加简单高效了，省去了低效的交流和不准确人工转换。 这其实并不是一件简单的事情，不论是设计 DSL 语言、做类似编译器的工具，还是构建内存模型，都不简单，但一旦上线，一切就变得简单了。而一开始按电信专家的需求直接实现协议的方法是更为容易的，但是就整个软件生命周期来看，它却不是一个简单高效的方法。 通过这个例子，你应该能体会到什么是简单、什么是容易，两者之间的差别。真正的简单是来自于不容易的，就像那句话说的，It's hard to simple，It's easy to complex，简单是很难的，复杂反而是很容易的。

5. 永远不要停止编码

跟大家分享的第五个感悟是：永远不要停止编码。这一点非常重要，对一个架构师来说，要永远记住自己是一个程序员。 作为架构师，我们可能设计了一个非常 high-level 的架构，但代码是软件的最终实现形态，每一个程序员在架构落地过程中的实现，都可能会影响架构的最终呈现。另外，如果你放弃编码，最大的影响不是说你代码的技术落后了，或者是敲代码变慢了，最大的影响是你会逐渐丧失对编程的敬畏，忘记作为程序员的感受，特别是编码过程中的那些痛苦所在。你会有一些不切实际的幻想，做出一些不切实际的设计，这才是最大的问题。 大家都知道的 Java 之父 James Gosling，他在 Amazon 的职位是 Distinguished Engineer，level 相当于 SVP，而他依旧在坚持编码，每年的代码量是非常惊人的，常常会超过 10 万行。 总而言之，作为一个架构师，一旦你开始放弃编码，那你一定要非常小心，因为你可能正在走向一条不归路，一条为大家设计一些充满幻想但又较为虚无的设计的不归路。

6. 风险优先

跟大家分享的第六个感悟是：风险优先。可以先思考一个问题，我们为什么要做架构设计？在我看来，架构设计最主要的功能就是转化、降低、避免整个开发过程中的风险。而架构师很大的一个职责就是在早期识别出系统可能存在的风险，并通过你的设计来转换它、去除它。 我们常说的原型方式，或者架构切片的快速迭代方式，其实也是从另一个角度在早期尽量去测试风险，去测试我们的架构能不能解决相关问题，尤其是那些非功能性需求实现的风险，这些风险往往没有功能性需求这么容易在初期被发现，但修正的代价通常要比修正功能性需求大非常多，甚至可能导致项目的失败。 比如敏捷开发，很多人认为敏捷开发就是更快地开发出一个产品，然后快速地 deliver 到市场上，其实这只是敏捷的一部分。另一部分很重要的是，如果一个项目要失败，也要快速地失败，绝对不要把风险放到最后，这也是一种敏捷。 这里再给大家推荐一本书《Just Enough Software Architecture（恰如其分的软件架构）》，这是最近非常流行的一本架构书籍，书中强调，架构设计的目的就是为了化解软件实现中的风险。如果你项目中所有的风险都可以通过未来重构来解决的话，那你根本就不需要进行架构设计，直接等着重构就可以了。这也是我非常赞同的观点，风险优先。

7. 从“问题”开始，而不是“技术”

跟大家分享的第七个感悟是：从“问题”开始，而不是“技术”。作为技术人员，我们非常乐意学习一些新技术，并且学了之后，我们还会非常有热情去应用这个技术。我经常会有这样的感觉，感觉在某一时刻被某个技术上身，特别想去实践它，以至于忽略当前手上的问题用这个技术来解决是不是最合适的，不知道你有没有相同的感觉。 冷静的时候，其实我们每个人都知道，要从实际出发，从需求出发，从用户的问题出发，而不要从技术出发，但在实际工作中，我们却常常不自觉地忽略这一点。就像手里有了一把锤子，看到什么都是钉子。 但其实这样做有很大的害处，这里想给你分享一个故事，来自我之前工作过的一个团队。当时团队里有一个工程师，他维护的是一个非常简单的服务，就是一个利用 MySQL 作为数据存储的简单服务。后来一个他对当时新出的 DynamoDB 产生了兴趣，并学习了相关知识。然后就发生下面的事：   使用 DynamoDB 替换了 MySQL，这是一个噩梦的开始。   很快发现 DynamoDB 并不能很好的支持事务特性，在当时只有一个性能极差的客户端类库来支持事务，而由于采用客户端方式，引入了大量的额外交互，导致性能差别达 7 倍之多，效率非常之低。   这时候，这个同学就改用了当时在 NoSQL 领域广泛流行的最终一致技术，采用了一个消息队列来实现，这样每一个数据存储对象的改变都会发布一个消息，如果关心这个改变的业务逻辑，就会订阅这个消息，然后改变其他相关的对象，从而实现最终一致。如果过程中出现错误，就会利用消息队列的重试机制。   接着发现 DynamoDB 无法提供 SQL 那样方便的查询机制，为了进行数据分析就采用 EMR/MapReduce Job 来完成。 大家可以看到实现一样的功能，但是复杂性大大增加，维护工作也由一个人变成了一个团队。如果让我总结一下这个故事的话，可以说是我们对技术的热情让事情变得复杂，是我们对技术的热情把生活搞得没有那么美好，也让自己的工作更加烦恼。

8. 过度繁忙使你落后

跟大家分享的第八个感悟是：过度繁忙使你落后。对于 IT 人而言，忙碌成了习惯，加班常挂在嘴边，“996”似乎也变成了公司高效的标志。 但有时候我们需要反思一下，有多久没有在业余时间看和技术相关的书了。我之前在公司也问过这个问题，百分之百的人回答我，下班后已经很晚了，回到家基本上没有时间再看书，刷一下手机，就可以直接睡觉了。 这是一个非常值得我们去思考的问题。作为一个技术人，如果你不更新你的知识，或者繁忙让你没有时间更新知识，那会有什么样的结果呢？ 给大家分享一个有意思的现象，我遇到过不少程序员，有之前的同事，也有自己的朋友，他们换了一份工作，一开始进入那家公司的时候跟我说，“这个公司我不是特别看好它，我了解一下它的技术，就准备换家公司。”过了两三年我再问他，“你怎么还在这，还没跳走。”结果他回答我，“我看现在的招聘形势不大好，不太好动。” 干了几年倒对公司越来越“忠诚”了。实际情况是，在一个公司没日没夜地干了几年，没有留一点学习时间给自己，忙碌的工作导致他没有时间更新知识，再想回到市场上的时候，却发现自己已经落伍了，连跳槽的能力和勇气都失去了。 在这个高速发展的时代，如果因为过度忙碌，导致你没有时间学习和更新自己的知识，那必然会让你落后。 即使你不跳槽，呆在同一家公司里，公司的业务不断发展，数据量会越来越大，用户需求会越来越***钻，你要面对的问题和场景也会越来越复杂，如果你长期不更新知识，掌握的技能没有发生变化，你会觉得越来越难以应付，最终只能通过不断地加班来应对。 另外还有一种可能是，你不更新知识，不深入思考，那么很大概率，你所创造的技术和业务丧失了领先性，没有领先优势，只能被动紧紧跟随竞争对手，而紧紧跟随就意味着你只能加班。试想一下，你要是都领先同行业五年了，还会在乎通过加班来早一个月发布吗？ 这其实是一个恶性循环，你花越多的时间去忙碌，就越没有时间去学习，去提高自己的工作技能，就只能靠加班来追赶，结果就更忙碌，更没有时间学习，最终成为一个井底之蛙，陷在恶性循环里无法挣脱。 我是一个健身爱好者，练过健身的朋友都知道，光靠锻炼是不行的，营养的补充和锻炼同样重要，你得专门吃一些蛋白粉、补剂之类的。而且越到后面，营养的重要性就越高，至少能跟锻炼达到 50:50 的比重。 个人技术成长其实也是一样的，锻炼就好像实践，营养就好像学习。人们常说 practice makes you perfect，但光 practice 是不行的，还需要坚持学习。 我们在一个领域工作了一段时间，比方说三五年之后，会对这个领域的业务越来越熟悉，解决问题越来越顺手，但相应的，能学到的知识和技能也就会越来越少。有些人会说这是进入了舒适区，要逃离舒适区，换一个领域，我倒觉得不必如此。本质上来说，换一个领域其实是促进你进一步学习一些新的知识，你在原来的领域也可以这么做。你可以有意识地摆脱那种麻木，挤出时间来重新学习，然后即使做的是相同的事情，也可以用不同的方式更好更高效地完成它。你会发现，即使在同一个领域，你也完全可以做和别人不一样的事情。 所以，每个技术人员都要保证充足的学习时间，否则很容易成为井底之蛙，从而陷入前面提到的低效循环。

标签：感悟,需求,功能性,一个,十年,简单,架构,我们
From： https://www.cnblogs.com/cytc/p/17629745.html