《大型网站技术架构演进与性能优化》之分布式改造[一]

1.分布式改造必须先解决以下几个问题:

第一,应用需要微服务化。即将大量粗粒度的应用逻辑拆小做服务化改造
第二,必须先建立分布式服务框架。必须具备分布式配置系统、分布式RPC框架、异步消息系统、分布式数据层、分布式文件系统、服务的发现、注册和管理。
第三,必须解决状态一致性问题。

2.典型的分布式架构

横向扩展,主要用来解决应用架构上的容量问题。由于单台服务器能支撑的服务能力始终是有限的,所以我们在架构上就必须做到能够支持横向服务能力的扩展。
纵向扩展,主要解决业务的扩展问题。当业务不断扩展时,业务逻辑的复杂度也会不断上升,所以在架构上要能根据功能的划分进行纵向层次的划分。

3.分布式中间件

首先要有一个统一的负载均衡系统(LB/LVS)帮助平均分配外部请求的流量,将这些流量分配到后端的多台机器上。
请求达到服务层,就需要解决服务之间的系统调用。包括同步调度的分布式RPC框架、异步调度的分布式消息框架、解决静态配置信息的分布式配置框架。
请求到达数据层。需要解决以下问题:第一,屏蔽不同数据库的差异性,使底层数据库的切换不影响上次应用代码。第二,屏蔽应用层代码对数据分布的感知,使对数据的分区或分片不会影响应用代码的编写。

4.分布式配置框架

拉取模式和推送模式。
一般而言,如果对配置下发延时率比较敏感而且Client数据不是太大(千级别)时,推荐推送模式;
而当Client数据在万级别以上时推荐使用拉取模式。

5.分布式RPC框架

服务注册
服务发现
服务调度和负载均衡
统一的SDK封装:服务框架需要提供一个统一的客户端和服务端的标准接口规范,这样可以减少业务开发的重复工作量。例如SDK会统一封装通信协议、失败重试以及封装一些隐式参数传递(trace信息)。
Java通过提供一个统一的jar包,封装了服务发布和调用的接口,业务层只需要做些简单的配置就能方便调用服务。

6.分布式消息框架

开源的RocketMQ、Kafka等
异步解耦:可以分开调用者和被调用者的处理逻辑,降低系统耦合,解决处理员之间的差异、数据结构之间的差异以及生产消费和消费者的速度差异。
最终的致性:一致性要求不能丢消息,保证消费最终可达,如果最终不可达要反馈给发送方。
多消费端:一个消息是被多个订阅者消费是典型的一种应用场景,多消费端非常适合用在单一事情触发的场景中。
延时消息:典型的应用场景是比如预订一张电影票的订单产生后,用户在15分钟后仍然没有付款,那么系统会要求在15分钟后取消该订单,释放座位。
典型问题:
确认消息会否被消费(需要增加消费确认标识)
消息队列需要有容错能力(当某个消息失败后,可以恢复重新投递消息)

7.分布式数据层

主要解决数据的分库分表、主备切换以及读写分离等问题。
读写分离要注意读写一致性的问题。

8.分布式文件系统

开源的TFS、FastDFS、GFS等,它们主要解决的是数据的高可用性和高性能问题。

9.应用的服务化改造

应用分层设计
通常从垂直方向划分应用,分成服务层、业务逻辑层和数据层,每一层尽量做到解耦:上层依赖下层,而下层不要反向依赖上层。
应用分层最核心的目的是每个层都会封装一些信息、完成一些特定的功能需求,层与层之间通过接口交互,而且交互的数据是清晰和固定的,做到隔离和交互。

可以从以下两个方向判断分层是否合理。
第一,如果我要增加一些新需求或者修改某些需求时,是否能清楚地知道要到哪层去完成,换句话说,这些分层的职责是否清晰。
第二,如果每个层对我的接口不变,那么每个层内部的修改是否会导致其他层也发生修改,即每个层是否做到了收敛。

微服务化
是从水平划分的角度尽量把服务分得更细,每个业务只负责一个功能单元,这样可以把这些微服务组合成更大的功能模块。也就是有目的地拆小应用,形成单一职责从而提升系统可维护性、扩展性和开发效率。

10.分布式化遇到的典型问题

集群管理:例如Zookeeper的Leader选举
共享锁:通过使用Zookeeper实现
队列管理:同步队列和FIFO方式进行入队和出队操作
通过使用Zookeeper实现

11.典型的分布式集群设计思路

当前的分布式集群管理中通常由两种设计思路:一种是Master/Slaver模式;一种是无对等的设计思路。

12.总结

分布式应用需要解决的核心问题:
第一,纵向业务逻辑的分层拆分,要方便不同工种的程序开发人员的协作。例如前端和后端开发人员的协作效率。
第二,横向不同业务系统的拆分,例如商品和会员系统独立。
第三,系统的横向和纵向的拆分必须首先解决好系统之间的连接问题,而这些系统之间的如何连接就是分布式系统必须解决的问题。


推荐阅读:
<<<《大型网站技术架构演进与性能优化》之无线时代下的构架演进[二]
<<<《大型网站技术架构演进与性能优化》之大中台小前台[三]
<<<《大型网站技术架构演进与性能优化》之全球部署方案[四]
<<<《大型网站技术架构演进与性能优化》之代码级优化[五]
<<<《大型网站技术架构演进与性能优化》之合并部署[六]
<<<《大型网站技术架构演进与性能优化》之大秒系统的极致优化思路[七]
<<<《大型网站技术架构演进与性能优化》之资源调度优化[八]
<<<《大型网站技术架构演进与性能优化》之大型网站的稳定性建设[九]

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容