遵循一些顶层的设计逻辑，降低架构设计中的错误，避免返工带来的大量人力成本。
用例用例用例
这才是是架构师设计的起点，新加入团队的研发理解业务逻辑的起点
通过用户访谈，提炼用户故事等手段，将上述内容转化为用例视图
说明谁要使用系统，以及他们使用系统做什么，是需求分析阶段的输出件。以用例作为设计的驱动，驱动后续的设计，随时回顾自己的设计是否能支撑用例，保证部署视图，逻辑视图，开发视图，运行视图正确性
提示：用户故事可以很好地帮你提炼用例视图
以分治法作为架构设计指导思想
架构边界画在哪里，系统架构间应该有一条不可跨越的实线，不同系统间不该感知或关注其内部结构
也是正交设计所说的关注点分离，保持组件间的松耦，架构演进的驱动力
爆炸半径控制
强关联可靠性，需要关注并罗列失败期间的全部功能降级。对于一款在线持续运行的服务需要提供长稳服务。在设计中需要熟知每种故障的影响，并尽量减轻影响面。适当的地方要进行功能降级，保证核心业务正常运转
核心链路审视要素
架构师为什么要审视核心链路，应该关注什么要素
让我们来看看Envoy作者的以下自述吧：
• 2012 年，我加入了 Twitter，在经历了几次错误的开始后，我最终加入了边缘网络团队。这是我第一次真正接触到分布式系统应用网络概念。我领导了一个新的 HTTP 边缘代理的开发，称为 Twitter 流式聚合器（TSA），它在 2013 年首次推出，以扩大 Twitter 的 “firehose” API（流式所有推文）的交付。在 2014 年世界杯前夕，我们决定将 TSA 作为一个通用的 HTTP/HTTP2/TLS 边缘代理，在靠近巴西赛事的存在点（POPs）推出。这样做的主要原因是不可能在 POP 的少量主机托管机架上部署现有的基于 JVM 的资源匮乏的边缘代理。项目周期特别紧张，我的团队成功地完成了一届没有事故的世界杯。（我还清楚地记得有一段时间，当软件崩溃时，不管是什么时候，我都会给自己打上一页，修复错误，然后重新进行金丝雀部署，继续测试）。在 Twitter 工作期间，我还接触到了该公司通过 Finagle 库进行服务间网络通信的方式，并取得了巨大成功。
• 2015 年元旦前后，我在 Twitter 的日子里，因为我写的一个 bug，TSA 系统故障导致数百万 Twitter 的安卓用户被下线，这将是我在 Twitter 工作的尾声。
• 我在 2015 年春天离开了 Twitter，部分原因是下线事件的影响，部分原因是对没有得到晋升的挫败感，部分原因是想尝试新的东西。我跟着我的老板从 Twitter 到了 Lyft，还有我在 Twitter 的其他同事。
可见，承载核心业务流量的组件是需要重点审视方案的。
以网关为例，开源有着诸多的网关方案，如果你要选型一个网关来承载核心流量，那么显然nginx，spring cloud gateway，envoy，APISIX等组件都可以作为备选，但是还要具体针对业务诉求再进行选型
开源软件选型核心要素：
• 是否成熟方案，经过很多的生产验证
• 最近的社区活跃度，包括提交，issue处理，资料是否很多
特性规格与设计约束
影响架构设计的因素很多，功能、质量。特别规格的满足度也是一点，需要和产品明确特性所需的规格，例如点赞操作需要在1秒内响应，短链需要保持24小时等，以减少设计期间的错误，落地后才引起不必要的返工，回退到设计阶段，这个成本是非常大的。大家都听过对上管理，对下管理，我管这个叫“对产品经理进行管理”。
看重API设计
API是架构的边界，需要格外审视，良好的API定义体现了服务设计的精妙，易用性、可读性、可维护性、性能皆会在此体现，就像是软件的“心灵之窗”。一个服务作为上游，需要为自己的下游服务持续提供长稳的服务，而其内部的设计是可以在保持不变的情况下进行改动的，良好的API设计意味着长期不变的兼容性，这也同时支撑了向稳定组件依赖的设计原则。可以自行搜索Facade模式进一步体会API设计在Facade模式下的重要性
