业务意识
需求来自何处？
C 端产品可能来自于用户反馈或用户调研；B 端项目可能来自于客户；也可能是业务挖掘出来，或老板的决定。
真需求还是伪需求？
开发功能和系统并不是需求，需求是解决问题，而问题是用系统的用户或者客户问题，功能和系统只是解决问题的一种答案。
由于沟通传播的递减效应，听到的需求可能不是最初的需求。因此接到需求时，要回溯，明确需求是在什么背景下提出的，解决用户什么问题。
产品手段 vs.技术手段
对于业务问题，产品经理会考虑用产品的手段解决，技术人员会考虑用技术的手段解决。
相信很多人都听说过搜索引擎的输入框增长的案例：最初做搜索引擎的时候，研究人员发现，如果用户搜索时多输入几个字，搜索结果就会准确得多。那么，有没有什么方法能提示用户多输入几个字呢？有人想到能否做一个智慧化的问答系统，引导使用者提出较长的问题呢？但是，这个方案的可行性会遇到许多挑战。也有人想到，能否主动告诉用户请尽量输入更长的句子，或根据使用者的输入词主动建议更长的搜索词呢？但是，这样似乎又会干扰用户。最终，有一位技术人员想到了一个最简单也最有效的点子：把搜索框的长度延长一半。结果，当用户看到搜索框比较长时，输入更多的字词的可能性更大。这就是一个典型的用产品手段解决用户问题的案例。
比如电商购物，为了应对高并发的库存扣减，对商品的库存做了分库分表。如果要同时对多件商品进行库存扣减，从技术上来说，这就是一个分布式事务问题。但实际上并不会这样解决，而是在产品层面解决。在产品层面，绝大部分场景都是一次把一种商品加入购物车，极少数有需要一次性加多个商品的场景。比如，要把收藏夹里面的多个商品一次性地加入购物车，这时可能出现部分库存扣减成功，部分库存扣减失败的情况，在产品层面提示哪些商品没有成功加入购物车，让用户重试，而不是试图用分布式事务解决。
再比如很多的后台报表统计类系统，为了降低技术的实现难度，采用分钟级、甚至小时级或天级别的报表，而不是实时统计。这也是典型的通过产品的设计解决技术问题的案例。
需求的优先级
什么叫做业务？
既然谈“业务架构”，首先要从一个技术人的视角来看，什么可以被称为一个“业务”。下面举了几个例子：
案例 1：美团点评公司，做团购、外卖、餐饮、生鲜、休闲娱乐、丽人、结婚、亲子、配送、酒店旅游、出行……请问，这家公司有几个“业务”？
如果以外部公布的最新的组织架构来看，这家公司主要有四大业务：
- 到店（包括餐饮、团购、休闲娱乐、丽人、结婚、亲子……）
- 大零售（外卖、配送、生鲜）
- 酒店旅游
- 出行（打车）
但如果以一年前的组织架构来看，这家公司有三大业务：
- 餐饮类（团购、外卖）
- 综合类（休闲娱乐、丽人、结婚、亲子……）
- 酒店旅游。
请问，这种划分的逻辑是什么？
“综合类”业务是再分成一个个的子业务，还是当作一个整体来看？
除这些之外，请问“广告”算作一个业务，还是一个平台？
支付与金融算作一个业务，还是平台，或者二者同时有之？
案例 2：把上面的例子细化一下，对于广告，通常有几种不同的计费方式：CPC（效果广告）、CPM（展示广告）、CPT（按时间段付费广告）。
- 第一种分法，把这三种广告认为是三个业务，三个不同的团队做（各有各的产品、技术、运营）。当然有一些公共的实施，比如账号体系。
- 第二种分法，认为这是一种业务的三种玩法而已，一个团队做，整合在一起考虑。一套技术架构同时支撑三种玩法（比如同一个位置既可以按 CPM 卖，又可以按 CPT 卖）。
案例 3：电商平台，有 B2C、C2B、C2C、海淘和海外。
这是五个业务，还是一个业务，或是三个业务？
- 第一种分法，认为这是一个业务，产品、技术、运营各一套技术架构，支撑不同的玩法而已。
- 第二种分法，认为是三种业务，国内、海淘、海外三个团队，只是账号体系、技术基础实施共用而已。
- 第三种分法，认为是五个不同的业务，五个团队各做各的。同第二种一样，某些基础设施共用。
案例 4：把案例 3 进一步细化
电商的“供应链”是否是一个业务？
前端的“搜索”，是否是一个“业务”？
通过上面几个案例：一个内容是否算作一个“业务”往往与公司的长期战略、盈利模式、发展阶段、组织架构密切相关，并没有一个标准的划分方式。但抛开这些差异性，一个内容能称为一个“业务”，往往具有一个特点，就是“闭环”。
什么叫闭环？
- 团队闭环：有自己的产品、技术、运营和销售，联合作战。
- 产品闭环：从内容的生成到消费，整条链路把控。
- 商业闭环：具备了自负盈亏的能力（即使短期没有，长期也是向这个发展方向）。
- 纵向闭环：某个垂直领域，涵盖从前到后。
- 横向闭环：平台模式，横向覆盖某个横切面。
同时闭环可大可小。
- 小闭环：一个部门内部的某项内容有独立的产品、技术、运营团队，独立运作。
- 大闭环：事业群、事业部级别，公司高层战略来决定的。
- 更大的闭环：产业上下游，构建完整的生态体系。
“业务架构”的双重含义
前面的案例讨论的“业务”，其实对应的是“业务架构”一词的字面意思，也就是“业务的架构”。这通常关乎大的战略，主要是从商业角度去看，公司高层领导决定的。
但对于技术人员来说，讨论业务架构的时候其实并不是这个意思，而是理解为另外一个意思：“支撑业务的技术架构”。注意，这里的落脚点在技术上，是从技术的视角看业务应该如何划分。本书主要讲的是第二个层面的意思。
业务架构既关乎组织架构，也关乎技术架构，所以很有必要探讨业务架构、组织架构和技术架构三者之间的关系。
（1）先说业务架构的第一重意思。从理论上讲，合理的团队的组织架构应该是根据业务的发展来决定的。不同的公司在不同的发展阶段会根据业务的发展情况，将壮大的业务拆分，萎缩的业务合并。拆分到一定的时候又合并，组织架构相应地跟着调整，相应的技术团队跟着整合，技术架构自然也会跟着变化。这种变化规律在半个世纪前就已经被提出，也就是“康威定律”：一个组织产生的系统设计等同于组织之内、组织之间的沟通结构。这也意味着：如果组织架构不合理，则会约束业务架构，也约束技术架构的发展。而组织架构的调整涉及部门利益的重新分配，所以往往也只能由高层来推动。
（2）业务架构的第二重意思。“支持业务的技术架构”，业务架构和技术架构会相互作用、相互影响。举个例子，对于广告业务，如果认为 CPC、CPM、CPT 是三个业务，可能会各自设计三套技术架构方案，并让三个团队去做；但如果认为是一个业务，会思考这三者之间哪些是共用的，哪些又是个性化的，尽可能把三者通过一个技术架构支撑，让一个团队去做。
这种技术的思考会反过来影响业务，重新思考团队的组织方式，团队的组织方式又会变，接下来又会影响业务的发展方式。
既然“业务架构”指的是“支撑业务的技术架构”。那既牵扯业务，又牵扯技术，二者究竟如何区分？又如何融合？
“业务架构”与“技术架构”的区分
之所以要谈“分”，是因为经常遇到的情况是：明明是业务问题，却想用技术手段解决；明明是技术问题，由于技术无法实现，反过来将就业务；可能既不是业务问题，也不是技术问题，而是组织架构问题，是部门利益问题，是公司的盈利模式问题。
下面列举了技术架构要关注的一系列问题：
- 你的系统是在线系统还是离线系统？
- 如果是在线系统，需要拆分成多少个服务？每个服务的 QPS 是多少，需要部署多少台机器？
- 运行方式是多线程，多进程？还是线程同步机制，进程同步机制？
- 如果是离线系统？有多少个后台任务？任务是单机，还是集群调度？
- 对应的数据库的表设计？是否有分库分表？
- 数据库的高可用？主从切换？
- 服务接口的 API 设计？
- 是否用了缓存？缓存数据结构是怎样的？缓存数据更新机制？缓存的高可用？
- 是否用了消息中间件？消息的消费策略？
- 是否有限流、降级、熔断措施？
- 监控、报警机制？
- 服务之间的数据一致性如何保证？比如分布式事务。
- ……
通过上面一系列问题可以看到，技术架构涉及的都是“系统”“服务”“接口”“表”“机器”“缓存”这样技术性很强的词语。这些是开发人员直接可以通过写代码实现的，很务实，没有虚的内容在里面。
把上面这些内容梳理一下，归类并起个名字，就变成了我们经常挂在嘴边的各种架构词汇：
- 物理架构（物理部署图）；
- 运行架构（多线程、多进程）；
- 数据架构（数据库表的 schema）；
- 应用架构（系统的微服务划分）；
- ……
伪分层
- 底层调用上层。比如某个基础服务调用上层的业务服务，怎么解决呢？
- 方案一：业务逻辑是否放错了位置？业务逻辑是否需要一分为二，一部分在基础服务，一部分在业务服务。
- 方案二：依赖反转。底层定义接口，上层实现。
- 同层之间，服务之间各种双向调用。比如业务服务 1、业务服务 2、业务服务 3 之间双向调用。
- 职责划分是否有问题，出现服务之间的紧耦合？
- 是否有个公共服务，独立于业务服务 1、业务服务 2、业务服务 3？
- 层之间没有隔离，参数层层透传，一直穿透到最底层，导致底层经常变动。比如
if version = xxx。 - 聚合层特别多，为了满足客户端需求，各种拼装。遇到这种情况，往往意味着业务服务层太薄，纯粹从技术角度拆分了业务。而不是从业务角度让服务成为一个完整的闭环，或者说一个领域。
边界思维
对象层面：SOLID 原则中，单一职责原则。一个函数、一个类、一个模块只做一件事。
接口层面：应将系统作为一个黑盒，思考对外提供的接口是什么。接口也就是系统的边界。接口定义了系统可以支持什么、不支持什么。所以，接口的设计往往比接口的实现更重要！站在使用者的角度来看，并不在意接口如何实现，而更在意接口的定义是否清晰，使用是否方便。具体来说，就是：接口的输入、输出参数分别是什么？哪些参数可选，哪些必选？如果输入参数很多，为什么不是分成多个接口？设计策略是什么？接口是否幂等？各种异常场景，接口的返回结果都是什么？
产品层面：把复杂留给自己，把简单留给用户。
组织架构层面：各部门之间的边界清晰，避免踢皮球或者抢着做的情况。
当谈到系统的时候，首先要确定的是系统为哪几类人服务，同哪几个外部系统交互，也就确定了系统的边界。
非功能性需求分析
并发性。对于 C 端的系统，大家首先关注的是系统能抵抗多大的流量。说通俗点，是可以承受多少人同时访问。常用的衡量指标是 TPS 和 QPS，平均响应时间/最大响应时间，并发数。
可用性。从服务角度来说，一个服务不可用有两层意思：
- 机器宕机，不能对外提供服务，直接抛错；
- 机器虽然没有宕机，但是超时。这涉及“性能”问题。
一致性。比如数据库的参照完整性、事务、缓存与数据库数据同步、多备份数据一致性问题。
稳定性和可靠性。稳定性和可靠性的界限很模糊，此处不深究两个词到底有何本质差别，只想说明这两个词指代什么？
“稳定性”指系统没有任何未定义的行为，体现在如下几方面：
- 所有的 if-else 语句里面，没有不处理的分支；
- 所有的 API 调用，每种异常返回值都有处理；
- 考虑内存、磁盘的上限；
- 系统不会时不时冒出一个问题出来；
- 出了问题，有很好的日志监控，能快速修复；
- 系统的 QPS 不会有抖动（除非业务有变化，比如大促），是一条平滑的曲线；
- 发布新版本，有回滚方案；
- 新系统上线，灰度平滑切换；
- Monkey Test？压力测试；
……
可维护性。与可维护性密切相关的是“可理解性”，或者说“代码可读性”。体现在如下几个方面：
- 系统架构设计简单，接口简洁，表数据关系清晰；
- 老人离职，新人接手，无须很长时间就能厘清代码逻辑；
- 系统功能不耦合，改一个地方不会牵动全身；
- 系统某些模块即使时间久远，也有人能厘清内部逻辑；
……
可扩展性。体现在如下几方面：
- 来了一个新需求，伴随一些新功能，可以在现有系统上灵活扩展；
- 没有地方写死，可以灵活配置；
- 容易变化的逻辑没有散落在各个系统里面，不需要多个地方跟着一起改。
可重用性。体现在如下几方面：
- 开发新的需求，旧的功能模块拿过来可以直接用。
先明确落脚点，或者说最终要达到的目的，即非功能性需求，再去想要达到这些目的可以用哪些技术手段。
视角
todo
抽象
略。
建模
14.8 章节。介绍的很迷糊。