分布式架构扩展立方体模型
扩展立方体模型从三个维度对分布式系统架构提出具体的要求，下面我们详细讲一讲：
（一）X轴扩展–水平复制
性能不够，设备来凑。通过 Nginx 负载均衡实现服务器集群，提高系统的高可用。因为其中任何一个服务器宕机，会有其他可用的服务器顶上，继续提供服务。
（二）Z轴扩展–数据分区
按照用户属性对应用/数据进行分组，比方说深圳的用户发起服务请求，经过网关路由器，网关路由器会优先选择将其转发到深圳应用实例，因为我们提前把深圳用户的信息存储到深圳应用实例当中，数据的访问和服务的处理速度会得到提升，提高了吞吐量。
（三）Y轴扩展–功能性分解
将单体应用拆分层一个一个独立的功能模块，耦合性降低，各小组维护好自己的功能模块即可。这些拆出来的功能模块可以在单独的服务器上运行，再结合利用前面的 XZ 轴提高 高可用/高并发。
分布式架构演化过程
（一）单点式架构
所有服务全部在一台服务器上，耦合度极高。
| 优点 | 缺点 |
|---|---|
| 开发迅速，成本低廉 | 性能差，并发量低 |
| 结构简单，维护方便 | 不具备可用性 |
| 事务强一致性 | 功能模块耦合严重 |
（二）应用集群架构
集群的后端服务器和集群的数据库解耦，我们还可以利用 MySQL 主从复制以及读写分离来提高数据一致性和性能提升，再不济还可以进行分库分表处理。这的确突破了单体服务架构的不可用性，引出的数据库相关问题也有对应的解决方案。
| 优点 | 缺点 |
|---|---|
| 突破单点性能瓶颈 | 功能模块耦合严重，即所有功能全部部署在一个服务器上，每个服务器都是如此 |
| 应用扩展方便 | 共用数据库，数据严重耦合，即读服务器虽然有多个，但是共用同一个写服务器 |
| 用户与后端解耦 | 数据库服务器成为瓶颈 |
| 事务强一致性 |
痛点 1：代码难以复制、难以同步
痛点 2：过分关注细节、开发复杂性过高
痛点 3：SQL 质量无法保证
痛点 4：基础数据与业务数据耦合严重
将功能进行模块划分，分散给各小组负责，同事每个功能模块维护自己的数据库，可以对上述问题进行应对。
（三）服务化架构
服务化架构单独剥离出服务层， 将上层应用抽象出可通用的功能、数据模型与储存设施， 使应用模块间实现彻底解耦。
- 消除代码级别重用，改用远程调用（RPC）
- 屏蔽实现细节，让业务开发更简单
- SQL 可用，专人负责更易维护
- 分工明确，数据解耦
那服务化架构就没有它的问题？按照当前发展，服务化架构的下一个发展就是微服务化，微服务的整体架构就是为了应对服务化架构引入更多服务存在的问题。
如何评估系统流量
哪些指标需要进行容量评估？
不同的服务容量评估方向不同，要发觉系统的复杂性和主要矛盾。比方说某鱼与某牙直播核心就是用户流畅观察直播，重点关注对象就是活动带宽；外贸交易系统核心就是资金的转移，核心就是交易的安全性和实时性。
下面用一个具体的案例进行分析：
因此，我们需要评估 QPS 即可。我们可以从产品经理那里拿到过往的业务访问趋势图，来看看哪个时间段是 QPS 最高，最高到多少。如果没有这份资料，可以根据二八原则。
计算出 QPS 峰值之后，需要对单机的能力进行测试，用压力测试工具，再进行必要的调整，有时候不一定就是服务器本身的局限性。
对此，我们评估计算如下：
- 无历史数据，按二八定理，预期QPS峰值不低于 2220
- 单点设备QPS极限为 400
- 假设采用IDC LBS负载均衡，不考虑带宽等因素
- 假设生产性能基线为80%
- 服务器应准备 2220 / (400 * 80%) ≈ 6.93
- 为此准备7台应用服务器即可
如何发现与分析架构核心复杂度
（一）案例一：公司内部推行物联网建设
（二）案例二：X电商门户
数字 16 代表一个每天可能的访问时间为 16 小时，排除 8 小时睡眠之后的结果。
计算出平均 QPS 为 694，但是电商访问有高峰期，我们 乘以 4 来应对这种情况。然后 除以 1000 * 0.8，这 0.8 代表单台服务器的极限，我们不希望服务器的极限是 满的，不然服务器随时处在崩溃边缘并不好。
最终计算出结果为部署 3 台。实际情况中，我们还会额外提供 1~2台备用，来提高高可用性。
（三）案例三：联通系统与XX银行平台问题
可见有时候不单是技术上的问题，架构设计是一个全局的考量，人员也在考量以内。
（四）思考题
（五）常见核心复杂性总结
优秀架构设计的指导原则
- 没有场景的架构设计就是耍流氓
- 发现问题的复杂性是根本，这些包含在用户关键需求中
- “解耦”是架构设计无时无刻考虑的事情
- 不要脱裤子放屁，好的架构设计一定是简单粗暴的
- 尊重”爬->走->跑->跳”的自然规律，架构一定是演化而来的
- 没有任何一个架构是”万金油” ，架构成长没有捷径
- 架构师千万不能为了”炫技”进行设计，否则整个公司要为之埋单
- 好的架构师一定是一个”聆听”的高手，跟客户交流要说人话
