“ 来自&＃xff1a;随行付研究院&＃xff08;ID&＃xff1a;arch_topii&＃xff09;
作者&＃xff1a;马铁利&＃xff0c;TGO鲲鹏会北京分会会员&＃xff0c;10年全栈工程师&＃xff0c;擅长微服务分布式架构设计。主要负责架构部日常管理&＃xff0c;参与构建微服务平台周边基础设施及中间件&＃xff1b;负责随行付对外开源等事宜。”
背景
对于现在的微服务架构的应用来说&＃xff0c;对大量并发的及时响应是一项制胜能力。据用户行为分析平台统计&＃xff0c;随行付的某一款APP产品每日请求就达到上千万次用户请求、加解密服务3000万次/日等等。这些微服务每时每刻在处理如此高强度的请求&＃xff0c;对数据层的应对能力要求极高。如果我们把对速度的需求放在复杂的分布式数据架构背景下&＃xff0c;是很难想象如何让应用应对如此巨大的数据访问量的。但很幸运&＃xff0c;我们有方法做到。即立方体模型。
立方体模型
可扩展的分布式系统架构设计有一个朴素的理念&＃xff0c;就是&＃xff1a;通过加机器就可以解决容量和可用性的问题。
对于一个迅速增长的应用而言&＃xff0c;容量和性能是首当其冲要面临的问题。但随着时间的向前推移、应用规模不断的快速增长&＃xff0c;除了面对性能与容量的问题外&＃xff0c;还需要解决功能与模块数量上增长带来的系统复杂性问题、业务变化带来的差异化服务问题等。而多数情况下应用设计之初出于诸多因素的考量&＃xff0c;并没有充分考虑或在设计之初就将此类问题提上日程&＃xff0c;导致系统的重构成为常态&＃xff0c;从而影响业务交付能力。对此&＃xff0c;「架构即未来」一书中提出了更加系统的可扩展模型&＃xff0c;可扩展模型是一个富有启发性的方法&＃xff0c;描述了微服务三个维度的扩展方法&＃xff0c;可以通过它来了解微服务架构的扩展维度。
X轴&＃xff1a;横向扩展模式&＃xff0c;关注水平的数据和服务克隆
Y轴&＃xff1a;功能分解模式&＃xff0c;关注应用中的职责的划分
Z轴&＃xff1a;数据分区模式&＃xff0c;关注服务和数据的优先级划分
X轴扩展
X轴扩展是通过绝对平等的复制服务和数据&＃xff0c;以解决容量和可用性的问题。以乘坐火车为例&＃xff0c;因春运高峰集中&＃xff0c;乘客人数也是平时时的几倍、甚至几十倍。12306为了提高运力都会采用复制的方法&＃xff1a;增加火车数量。增加火车数量有效的提高春运运力、提高乘客出行体验。
对于软件工程而言&＃xff0c;比如加解密微服务的性能峰值1000TPS&＃xff0c;通常我们需要提高TPS&＃xff0c;会采取复制加解密服务&＃xff1a;增加服务提供者。这就是X轴扩展的一个完美示例&＃xff0c;说明了X轴扩展的思路&＃xff0c;把工作无偏向的分配给「复制品」&＃xff0c;各个「复制品」之间不共享任何内容、能独立提供服务。而对于软件技术来讲&＃xff0c;X轴扩展主要有负载均衡和数据复制两种技术方式。
负载均衡是将用户的访问请求通过负载均衡器&＃xff0c;均衡分配到由各个「复制品」组成的集群中去。当某个「复制品」出现故障&＃xff0c;也能轻易地将相应「工作」转移给其它的复制品来「代为完成」。常用的硬件负载有F5、A10&＃xff0c;软件负载Nginx。
这中间涉及到的技术点包括了反向代理、DNS轮询、哈希负载均衡算法&＃xff08;一致性哈希&＃xff09;、动态节点负载均衡&＃xff08;如按CPU&＃xff0c;I/O&＃xff09;等。它的难点在于要求集群中的「复制品」是不共享任何内容&＃xff0c;也就是我们常说的无状态。
数据复制是指在数据存储层进行绝对平等地数据迁移&＃xff0c;用于解决存储层I/O瓶颈以及可用性上的问题。有多个「复制品」存储&＃xff0c;使得每个「复制品」提供无差异的数据服务&＃xff0c;我们需要在「复制品」之间同步或异步的复制数据。
数据复制的方式包括了主从同步(读写分离)、双主同步等。因为数据存储天生就是有状态的&＃xff0c;数据复制的难点在于如何保证一致性。为保证一致性&＃xff0c;衍生了很多复杂的技术和中间件&＃xff0c;比如Paxos选举算法、随行付Porter数据同步中间件等。
多数情况下我们的应用中都会存在热点模块&＃xff0c;我们可以理解为越基础的模块越容易成为热点模块。热点模块更加容易成为整个平台的瓶颈点&＃xff0c;所以热点模块要尽早的采取扩展措施&＃xff0c;扩展措施一般都采用X轴扩展方式。
其实在我们开发过程中&＃xff0c;经常会给pc端、mobile、app端各自研发一套前端。其实对于这三端来说&＃xff0c;大部分端业务逻辑是一样的。唯一区别就是交互展现逻辑不同。如果controller层在后端手里&＃xff0c;后端为了这些不同端页面展示逻辑&＃xff0c;分别维护这些controller&＃xff0c;徒增和前端沟通端成本、在扩展性上面也不能达到很方便的扩展。前后端分离的好处在于&＃xff1a;
提升适配性
提升响应速度
提升性能(分后端可分别优化)
Y轴扩展
Y轴扩展是根据数据的类型或者交易执行的类型&＃xff08;或者两者都有&＃xff09;来划分工作职责。一般称为面向服务或面向资源的扩展。
我们再以火车来举例&＃xff0c;12306根据起点和终点的不同&＃xff0c;划分了多条火车线路。每条火车线路的周期归属运输&＃xff0c;交付着乘客的出行服务。这样做的好处是明显的&＃xff0c;每条火车线路的任务更简单&＃xff0c;从而能更高效的提供出行服务。
与火车分工类似&＃xff0c;为了降低系统复杂度&＃xff0c;Y轴扩展会将庞大的整体应用拆分为一组服务。每个服务实现一组相关的功能&＃xff0c;如核心交易、风险控制等。而在软件上常见的方案是服务化架构(SOA)、微服务化架构(Micro Service)。
Z轴扩展
Z轴扩展是指基于请求者或用户独特的需求&＃xff0c;进行系统划分&＃xff0c;并使得划分出来的子系统是相互隔离但又是完整的。继续以火车举例&＃xff0c;12306为了更好发展业务&＃xff0c;交付出行体验。在中国建立N多个铁路局&＃xff0c;各个铁路局个行其责&＃xff0c;分别提供出行服务。这就是一种Z轴扩展。
对于软件而言&＃xff0c;Z轴扩展一般是为了满足差异性的需求、安全隔离而采取的扩展措施。比如&＃xff0c;为了提供VIP用户服务&＃xff0c;可以将系统完整地复制一份出来&＃xff0c;与普通用户所使用的系统完全隔离&＃xff1b;针对不同的地域用户&＃xff0c;系统自动切换到对应地域的子系统&＃xff0c;为用户提供服务&＃xff0c;都是Z轴扩展。另外&＃xff0c;在系统的灰度部署上&＃xff0c;我们也通常使用Z轴扩展来完成。
软件领域常见的Z轴扩展有以下两种方案&＃xff1a;分离化部署和数据分区。
在分布式服务设计领域&＃xff0c;一个烟筒状就是满足某个分区所有业务操作的自包含闭环。如上面我们说到的Y轴扩展的微服务架构&＃xff0c;客户端对服务端节点的选择一般是随机的&＃xff0c;但是&＃xff0c;如果在此加上Z轴扩展&＃xff0c;那服务节点的选择将不再是随机的了&＃xff0c;而是每个烟筒状自成一体。
为了性能及数据安全考虑&＃xff0c;我们将一个完整的数据集按一定的维度划分出不同的子集。一个分区&＃xff08;Sharding&＃xff09;&＃xff0c;就是是整体数据集的一个子集。比如用尾号来划分用户&＃xff0c;那同样尾号的那部分用户就可以认为是一个分区。数据分区为一般包括以下几种数据划分的方式&＃xff1a;
数据类型&＃xff08;如&＃xff0c;业务类型&＃xff09;
数据范围&＃xff08;如&＃xff0c;时间段、用户&＃xff09;
数据热度&＃xff08;如&＃xff0c;用户活跃度&＃xff09;
按读写分&＃xff08;如&＃xff0c;描述&＃xff0c;库存&＃xff09;
当然&＃xff0c;数据分区也是有代价的&＃xff0c;它将增加数据运维的难度&＃xff0c;关联搜索的复杂度增加等。
总结
X轴上扩展是平台或系统的交易量或工作量增长&＃xff0c;虽然X轴扩展能够很好处理交易量的增长&＃xff0c;但当系统复杂度的大幅度增加&＃xff0c;或用户数量增加以及差异化服务需求出现&＃xff0c;X轴扩展就难以应付了。但我们可以通过Y轴扩展来处理系统复杂度增长、Z轴扩展来处理差异性化需求。XYZ三个轴可以根据实际情况酌情使用其中一个、两个或三个&＃xff0c;三个轴既可以无限向下扩展也可以无限向上扩展。我们在设计系统架构时可将扩展立方体模型作为理论指导&＃xff0c;设计完之后回过头来验证是否可以做相应的扩展。
一个扩展性良好的系统&＃xff0c;会充分考虑三个维度上的可扩展性&＃xff0c;熟练运用三个维度的扩展性&＃xff0c;使得系统性能改善上有更多的方向&＃xff0c;但在系统性能优化上&＃xff0c;代码层面、框架层面、设计层面也是更加的至关重要。
架构文摘
ID&＃xff1a;ArchDigest
互联网应用架构丨架构技术丨大型网站丨大数据
更多精彩文章&＃xff0c;请点击下方&＃xff1a;阅读原文
京公网安备 11010802041100号