设计及实施过程中面临问题（点滴开始，并非一蹴而就）
- 起点：由于规模庞大，系统面临高并发、海量数据存储需求，将导致单体设计无法满足需求，支持水平硬件扩展的分布式架构应运而生。
- 调整：基于第一个问题，我们按功能进行服务的拆分，每个功能点都拆分成一个单体的服务（麻雀虽小，五脏俱全：从接口的对外发布功能到底层的数据存储，均在这个体系内），服务间调用使用RPC方式，并加入分布式事务功能，保证数据的一致性。
- 新问题：经过『调整』后的构架，在一定程度上提高了系统的吞吐量，但还远远达不到高并发，海量数据的需求，因为有些功能点的访问量还是会超出单体的处理能力，这就要求单个功能点也能支持硬件的水平扩展。
- 再调整：为了能支持更高的并发和海量的数据存储，这里先引出一个概念AKF(可以参考这篇https://www.cnblogs.com/guanghe/p/10978349.html）。基于AKF原理，这里主要讨论X和Y轴两个维度：
Z轴（数据分区）关注服务与数据的优先级划分，如按地域划分
Y轴（功能）关注应用中功能划分，基于不同的业务拆分
X轴（水平扩展）关注水平扩展，也就是“加速器解决问题”
对于Y轴，前面第2点其实已经实现，但是还不够细，也就是说如果基于功能拆分的服务是有状态的，那么它的水平扩展将会出大问题。所以接下来就要将按功能拆分的单体微服务转换成一个无状态的微服务，再去做水平扩展即可满足基本需求。
- 这里提一下Z轴主要解决的问题：比如我们的打车服务接口，一开始全部部署在华南的机房，深圳这边的用户用着是很爽，网速杠杠的，但是，北京的用户就是一直抱怨系统响应慢，明明服务器负载也是正常的呀。究其原因是网络链路问题，这个可以通过CDN来解决。基本思路就是根据区域用户数，在华南和华北部署一定比例的服务，再通过CDN加速（就近原则：通过对请求来源进行解析，将请求分发到最近的服务器上）即可。
网友评论