架构中的一切都是权衡
架构合理性讨论
对于架构合理性的讨论总没有停止过，不同的人站在不同视角下总会得到不同的答案，一个好的架构讨论应该基于现有系统最直接的痛点。
基本问题：取舍
每个架构问题的答案都包含了“这取决于……”，就是你有一个大的业务前提，这些前提也就决定了你之后落地架构的取舍。架构师需要解决的是Google搜索不到的问题，比如你没法在 Google 搜索是 REST 还是消息传递更好，是微服务好还是单体架构更好？你没法搜到缓存处理是cacheaside好还是cachethrough更好。
架构的定义
架构之所以这么难，因为每个人的环境、情况和问题都不一样。在架构中没有正确或错误的答案，只有权衡。所以架构的定义是：在特定背景下实现降本增效目的的解决方案。
发布-订阅消息传递 vs 点对点消息传递
发布-订阅模型的优势
- 增加“竞价历史”新服务不需要对现有系统进行任何修改。
- 解耦：生产者不需要知道数据有哪些服务在使用、如何去使用。
队列模型的优势
- 任何人都能访问发布-订阅模型的数据，存在数据访问和安全问题。
- 发布-订阅模型只能接受相同格式的数据，假设新的“竞价历史”服务需要当前的售价以及竞价，但其他服务原本没有这些信息，在这种情况下需要修改数据格式，并且会影响使用该数据的所有其他服务。在队列模型中，这将是一个单独的通道，因此是一个单独的格式，不影响任何其他服务。
- 发布-订阅模型不支持监控某个主题的消息数量，导致不支持自动缩放。
队列模型的劣势
- 在队列中很容易知道哪个队列消息量大，独立地自动伸缩。这种权衡是特定于技术的，高级消息队列协议（Advanced Message Queuing Protocol，AMQP）可以支持负载均衡和监控。
架构思维
架构思维就是要理解系统成功所需的业务因素，并将这些需求转化为架构特性（如可扩展性、性能和可用性）。这是一项具有挑战性的任务，要求架构师能够保持一定的技术深度。
避免瓶颈陷阱
架构师不是全职开发人员，需要在开发人员（编写和测试代码）和架构师（画图、参加会议，以及参加更多的会议）之间取得平衡。架构师如何才能保持亲力亲为并保持一定的技术深度呢？
四种基本方法
- 经常做 POC（proof-of-concept），通过考虑实现细节来验证架构决策。
- 处理一些技术债务或架构问题，让开发团队腾出时间来处理关键的功能开发。
- 通过创建简单的命令行工具和分析工具来帮助开发团队自动化完成日常任务，寻找开发团队执行的重复性任务，并将这个过程自动化。
- 经常做 code review。
知识金字塔
知识金字塔包括三类知识：
- 你知道的东西(Stuff you know)：日常工作中使用的技术、框架、语言和工具；
- 你知道你不知道的东西(Stuff you know you don't know)：略知一二但没有深入理解或没有专业知识的东西，例如：你可能听过 Clojure，但是不知道怎么使用这种语言进行编码；
- 你不知道你不知道的东西(Stuff you don't know you don't know)：你不知道这些东西的存在，是知识三角中最大的一部分。
对架构师来说，明智的做法是牺牲一些很难学到（hard-won）的专业知识，利用这段时间来拓宽自己的广度。这也是一种取舍。
