理解问题，然后技术

系统架构是进化而来的，是为了解决具体的业务问题而诞生和演化的，而并非技术人追逐前沿和炫技的产物。

如果说出这周的课让我感触最深的一点，就是上面这句话了吧。我们做技术做开发出身的，有时、甚至总是带有一丝傲气，这股傲气让我们看不起落后的技术，看不起除了自己追逐以外的其他技术栈，乃至于形成编程语言/前台后端/开发运维/的“鄙视链”，其实这些都不算是最要紧的，顶多当成茶余饭后的笑话来讲一讲，或者偶尔活跃活跃微信群、社区的气氛。

真正要紧的，是技术人有的时候会坚持技术至上的态度去面对问题和解决问题。这种态度尤其落到技术方案的设计和选型上，往往就很容易导致我们无法真正着眼于问题的本质。因为别人在用高可用技术方案，我们也要用；因为Serverless现在正火，所以我们也要用；因为微服务流行，所以我们也要用微服务；因为中台又成为了当下的趋势，所以我们又开始追逐中台。技术的更新换代实在是太快了，各种新的设计理念和实践方法又层出不穷，导致了我们习惯性地追求新和渴望更高的生产力。

但是我们可能忽略了最重要、最基础的一件事：业务需求和目标。

我记得在第一周的课程一开始，老师就分享了一个原则。那就是架构师的工作，从最开始，是需要首先识别出相关方的。这个相关方可能包括了客户、产品使用者、自己的老板、开发团队、测试团队和运维团队，每个相关方的关注点都是不一样的。做技术的人为什么创业很容易失败，总结的原因中最主要的一条是技术人没有产品的思维，不会站在用户和商业的角度去思考问题，说白了就是很少或者没有去考虑如何最大化变现的问题。

所以在我的理解中，在整个产品的生命周期中，技术是最不重要的一环，但是我们往往固执地坚持这一点。

如果用户量没那么多，我们是不是就不需要什么高并发；如果原本产品逻辑就并不复杂，我们是不是就不需要搞那么多的微服务拆分；如果产品只是内部用户使用，对性能并不敏感，是不是也不需要考虑高性能？

上面举的例子也许有些极端，但是我的重点在于：我们去做架构，一定要切中实际的业务需要，这才是最本质的问题，不要陷入到盲目的技术选型之中而忘记了我们要创造的是什么。做产品最重要的一点就是怎么用最小的成本、最低的代价实现业务目标。

产品从上线到后期多轮迭代，一开始的业务需求其实是很简单直接的，在每一轮的迭代中增加一些功能特性，也同时解决一些演进过程中逐步出现的问题。我们在面对这些问题的时候，首先要弄清楚问题的本质是什么，然后针对性地选用最高效的方法进行架构的演进。

如果是数据读写量大，就搞清楚是读多写少还是别的场景，针对不同的场景，选用最合适的方案。老师课上介绍的各种技术方案和技术手段，我就不在这一一列举了，课后作业里也都提到了。而且我们还要弄清楚这些常用的技术方案，解决的到底是什么问题，以及解决的思路是什么样的，一旦搞懂了这个思路，我们就不会知其然而不知其所以然，变成凭直觉去决策，无异于是给自己挖坑。

从课上举的几个例子来看，我们能很明显地看出这个架构演化的过程：每一步遇到了什么问题，怎么解决问题。难怪老师说最重要的能力是洞悉问题本质的能力。



至于何时意识到架构已经不足以支撑未来可预见的时间内的业务需求，也就是架构需要升级了，也是一个很重要的问题。我们当然不希望等到问题真的出现了，我们再去慌忙地做架构升级评估和落地，那会出大问题的。老师给出的回答是，当然要提前，我们可以通过有意的压力测试、制定业务目标并提前评估当前架构是否足以支撑业务目标等方式提前识别架构风险，及早进行瓶颈识别和设计升级。但我理解这并不是说，我们又可以陷入到技术人的想当然中，还是要从实际的业务目标出发来思考问题，脚踏实地。



所以，技术人，请暂时忘掉各种技术，去用心理解问题的本质。

附：在这里也顺手再多推荐几本书：

1. 阿里巴巴集团双11技术团队出品的《尽在双11——阿里巴巴技术演进与超越》

2. 携程技术团队出品的《携程架构实践》

这两本书系统性地讲述了阿里巴巴和携程这两个大型网站技术架构的演进和顶层设计方案，是理解业务场景需求和架构变迁很好的参考书。

1. 第三本是《演进式架构》，介绍了如何设计灵活架构的相关思考。