对于架构合理性的讨论总没有停止过，不同的人站在不同视角下总会得到不同的答案，一个好的架构讨论应该基于现有系统最直接的痛点，比如现阶段业务刚开始，重要的是快，单体架构有可能比微服务更好一些。这个阶段整个业务体量规模和所需要支持的规则其实不会对系统带来大的挑战。但是也需要注意一旦规模与规模膨胀之后，现有系统是否可以快速平滑的进行过度呢？这种扩展能力的抽象往往是对架构师最大的挑战。

架构首先要回答的问题是取舍。

每个架构问题的答案都包含了“这取决于……”，就是你有一个大的业务前提，这些前提也就决定了你之后落地架构的取舍，架构师需要解决的是Google搜索不到的问题，比如你没法在 Google 搜索是 REST 还是消息传递更好，是微服务好还是单体架构更好？你没法搜到缓存处理是cacheaside好还是cachethrough更好。

因为它确实取决于，取决于部署环境、业务、公司文化、预算、时间、开发人员的技能组合以及其他几十个因素。

架构之所以这么难，因为每个人的环境、情况和问题都不一样。

在架构中没有正确或错误的答案，只有权衡。

所以架构的定义是：在特定背景下实现降本增效目的的解决方案。

举个例子：

考虑一个拍卖系统，有以下两种数据消费模式。

发布-订阅消息传递

点对点消息传递

发布-订阅模型的优势：

假如我们要增加一个“竞价历史”新服务，则完全不需要对现有系统进行任何修改；

而在队列模型中，我们可能需要修改生产者添加一个队列；

解耦：

生产者不需要知道数据有哪些服务在使用、如何去使用；

而在队列模型中，生产者需要知道是什么类型的数据，发送给谁。

架构师的思维需要看到方案的好处和坏处。

队列模型的优势：

任何人都能访问发布-订阅模型的数据，存在数据访问和安全问题。

发布-订阅模型只能接受相同格式的数据，假设新的“竞价历史”服务需要当前的售价以及竞价，但其他服务原本没有这些信息，在这种情况下需要修改数据格式，并且会影响使用该数据的所有其他服务。在队列模型中，这将是一个单独的通道，因此是一个单独的格式，不影响任何其他服务。

发布-订阅模型不支持监控某个主题的消息数量，导致不支持自动缩放。

在队列中很容易知道哪个队列消息量大，独立地自动伸缩。这种权衡是特定于技术的，高级消息队列协议（Advanced Message Queuing Protocol，AMQP）可以支持负载均衡和监控。

鉴于这种权衡分析，现在哪个是更好的选择？答案是什么呢? 这就要看情况了! 

技术是服务于业务的。

架构思维就是要理解系统成功所需的业务因素，并将这些需求转化为架构特性（如可扩展性、性能和可用性）。

这是一项具有挑战性的任务，要求架构师具有一定程度的业务领域知识，并与关键业务利益相关者建立健康的协作关系。

每个架构师都应该进行编码，并且能够保持一定的技术深度。虽然这看起来似乎是一个简单的任务，但有时却相当难以完成。

架构师需要避免瓶颈陷阱。

当架构师掌握项目关键路径内的代码（通常是底层框架代码）的所有权，并成为团队的瓶颈时，就会出现瓶颈陷阱。

架构师不是全职开发人员，需要在开发人员（编写和测试代码）和架构师（画图、参加会议，以及参加更多的会议）之间取得平衡。

架构师如何才能保持亲力亲为并保持一定的技术深度呢？

有四种基本方法可以让架构师在工作中练习，而不必“在家练习编码”：

经常做 POC（proof-of-concept），通过考虑实现细节来验证架构决策。例如，如果架构师在两种缓存解决方案中无法抉择，那么可以每种缓存开发一个实例，并进行对比。

处理一些技术债务或架构问题，让开发团队腾出时间来处理关键的功能开发。这些问题通常是低优先级的，一般不会影响迭代。还可以在迭代中修复 bug，在帮助开发团队的同时也保持了编码，还可以找出代码库可能存在的问题和弱点。

通过创建简单的命令行工具和分析工具来帮助开发团队自动化完成日常任务，寻找开发团队执行的重复性任务，并将这个过程自动化。开发团队会感谢自动化。

经常做 code review。虽然并不是实际写代码，但至少参与了源代码的编写。此外，做 code review 还能确保代码符合架构的要求，帮助和指导开发。

知识金字塔

知识金字塔，包括三类知识：

你知道的东西(Stuff you know)：日常工作中使用的技术、框架、语言和工具；

你知道你不知道的东西(Stuff you know you don't know)：略知一二但没有深入理解或没有专业知识的东西，例如：你可能听过 Clojure，但是不知道怎么使用这种语言进行编码；

你不知道你不知道的东西(Stuff you don't know you don't know)：你不知道这些东西的存在，是知识三角中最大的一部分；

对架构师来说，金字塔最重要的部分是顶部和中间部分。

对于架构师来说，明智的做法是牺牲一些很难学到（hard-won）的专业知识，利用这段时间来拓宽自己的广度。这也是一种取舍。