备注说明：相关总结属于个人学习笔记，请勿商用，感兴趣的可在极客时间订阅该《乔新亮的CTO成长复盘》专栏学习，谢谢~
常见的扩展性设计是业务拆分、集群扩容
追求卓越的技术人，应该学会思考：我的工作是如何成就业务的，我的产品如何让用户变得更卓越？
如果对业务、对用户没有帮助，做再多的技术工作都是无用功。
让自己变得专业，专业才能成就卓越。不单是指技术。包括你在架构设计方面是专业的、在团队管理方面是专业的、在业务发展方面也是专业的。
定义：
扩展性设计，是为了支撑业务快速发展而出现的概念，目的是保证在企业发展的不同时期，
在业务复杂度相近的情况下，业务上线所需要的研发时间不会大幅增加，甚至是基本不变的。
本质上，所谓扩展性设计，就是在面向业务的不确定性做设计。
要具备企业发展的全局视角，从业务发展的角度出发，倒推出 IT 建设的整个链条，再针对链条中的某个节点，针对性地推进设计工作。
重要的前置思考脉络
强迫自己像 CEO 一样思考，首先理顺一条重要的前置思考脉络。
- 公司的年度 / 季度业务发展目标
- 企业级产品建设 （产品是企业用来支撑业务的发展和增长）
- 企业级应用架构设计（顶层设计，底层要由众多应用 / 业务组件支撑）
- 企业级技术架构设计 （应用架构又由众多技术组件在底层提供基础能力支撑）
团队管理内容纳入考量，分别是人才梯队建设和提升协同效率。
要考虑组织的人才梯队建设，包括 A/B 岗配置、同赛道竞争机制等。一旦将团队纳入设计，就要考虑协同效率的问题，不能因为业务增长、团队增长而引入协同问题。这两点，则全部属于团队管理范畴的问题。
实战步骤
保证企业级年度 / 季度业务发展目标实现聚焦
制定「企业级年度 / 季度业务发展目标」，需要在公司战略确定、商业模式确定的情况下，充分考虑市场竞争情况，确定目标的优先级，明确每个季度的工作目标。
用业务目标指导产品建设
确定了业务目标后，在规划产品建设时，
团队可以通过三步做好扩展性设计：
- 通过架构思维，将产品拆解为一个个功能模块；
- 针对每个模块，用穷举法思考其他扩展可能；
- 以 ROI （投资回报率-“收益 / 投入”）为出发点，对所有可能进行收敛，最终确定要落实的扩展性设计。
例子
扩展性思维的团队会思考：
在北京需要与对标对象 A 比对价格，在福州可能就是与对象 B 比对价格了，不同的地区可能会对系统功能有不同的需求。
进而，我们可以将一个价格比对产品的功能模块进行抽象，
包含：对标对象设置、对标商品映射、价格设定规则（上浮或者下调）、对标周期等，这样就可以满足全国各个区域的任何价格比对需求，支持业务的快速发展。
所以，产品能否具备高扩展性，是与产品经理的业务思维和抽象能力密切相关的。同时，如果产品设计做得好，应用架构的设计工作就会简单很多。
扩展性设计，为“不确定性”而设计
企业级应用架构设计可以包含：
- 交易体系；
- 协同体系
- 监控指挥体系
- 生产体系
例子：
生鲜行业的 To B 产品来说，查询、下单、发货、签收，是始终不变的业务流程，属于确定性部分。这部分的实现归属交易体系。交易体系处理确定性问题，一般采用 SOA 架构。 但在实际的业务场景中，意外会经常出现。比如，客户下单购买了 500 斤白菜，但在发货时，仓储系统却显示备货不足，无法正常发货。 此时，产品预设的服务流程就被打破了。企业一般会指派客服人员与客户联系，尝试着商量一下：“不好意思，我们的白菜只剩 300 斤了，剩下的 200 斤给您换成芹菜吧，芹菜多好吃呀！” 这个时候，我们就需要让采购人员、销售支持、销售人员联系客户，进行充分沟通，确定最终的商品品类及数量。这个流程属于协同问题，充满不确定性，也就是说，相比交易体系，更有可能随着公司的管理优化而进行变化。协同体系用于处理不确定性问题，一般采用 EDA 架构，且要和交易体系进行集成。
分离不代表完全无关，交易体系和协同体系的集成点，我称之为 CP（control point）。一般来说，任何一个 CP 都要被监控、分析、控制，这就是企业的监控指挥体系。监控指挥体系和公司的管理密切相关，往往是公司数据化管理的重要抓手。
企业级技术架构设计。
不要重复造轮子，至少不要在公司层级造轮子。
要实现技术架构体系中的各个技术平台，两步完成：
- 自研
- 购买相应的套装软件或云服务
对于非核心系统，在需求较为匹配的情况下，建议选择购买套装软件或云服务；对于高度定制化的企业核心系统，也就是在核心价值链上提供服务的系统，则建议自研。
总结：
真正优秀的扩展性设计，建立在看透业务本质的基础上，面向不确定性，但要从不确定性中寻找确定性。
