原文链接：老于聊架构
有关架构的书：
面向模式的软件架构、程序员必读之软件架构、企业应用架构模式、 一线架构师实践指南
以始为终的架构设计：
—— 满足或引导客户价值的挖掘和表达。
为什么要做架构
- 没有设计师的蓝图无法建造房屋
- 快速规模化、适应变化、解决客户问题
如何做架构
以终为始，不忘初心。初心：用户的本质需求
用户想要什么就给什么未必是本质需求
关注正确性和体验。
PBC框架：
- 平台（Platform）
- 商家（Business）
- 用户（Client）
平台的本质设计是符合用户侧、商户侧、平台侧的3端诉求的
司机和车只是它的资源，供应方（supply）可以是一家蛋糕店、鲜花店或者是西湖的休闲船只管理中心，那么它以下能力可以复用：
- 调度能力
- 用户呼叫的界面、策略
- 地理位置处理
- 交易事后处理等
大部分变化在于运送的物品（属性）以及一些附属需求，而这些都是可以通过良好的平台设计+可扩展的新市场产品特性来完成。
架构非单一视角，单一层次
架构的多层次多视角有助于厘清本质，对问题域更好求解
关注SLA
- 避免关注枝节遗忘全局
- 避免关注自身忘记出发点
比如从系统运行角度看，如何度量用户SLA（体验的顺畅度，支付成功率）以及更多行为数据（用户在哪一步流失的，什么原因），从下单到完成支付的花费时间是多少等。
要做这些，就需要全链路的监控，进而推之需要做统一的上下文，事件码来串联请求的链路（traceId技术语义，业务语义则可能是userId）。
####架构是什么
架构是演进而来的
无纯粹的非功能特性
下图为某平台的能力视图，容量，高可用能力，高性能都是和外部平台的要求匹配的
汇总
请度量你的产品对于用户、商户的SLA（接入效率、接入成本、用户体验、稳定性、应急处理能力等）
适当的时候考虑链路级业务监控视图
在系统链路调用上加上traceid这样的东东
考虑平台沉淀能力时考虑业务形态的扩展，比如uber只是一家解决出行的公司么？
在不同阶段采用不同架构，试水期说不定演烟囱型架构是最适合的，因为短期的价值是打一个点（业务上），让自己活下去（平台方）
非功能要素不是加分项，可能是主体价值体现点，比如商户需要一个批量导入接口，你提供了单笔处理接口，然并卵！