关于分布式系统架构模块通讯方式选择的问题
对于一个用户访问量比较大的互联网系统，当用户数达到一定数量时，系统总会存在瓶颈或处理极限，即很难做出快速响应，处理效率逐步低下。对于如何应对用户量不断增长的情形，较直观的方案就是采用分布式系统架构。所谓分布式系统架构，简单的理解就是原来由一台服务器处理的业务，现在分摊给多台服务器处理；原来由一组服务器组处理的业务，现在由多个服务器组处理。
本文多讨论的分布式系统架构是基于如下场景考虑的：整个系统分为Global（全局）和ServerGroup(服务器组)，系统中只有一个Global，但有多个ServerGroup。
Global：有对应的数据库和应用程序模块，存储全局性的基础数据及架构配置信息，对系统起全局控制作用，并协调各ServerGroup进行统一业务处理。
ServerGroup：系统根据指定的规则可以划分成若干个ServerGroup，每个ServerGroup负责指定范围内的业务逻辑处理。例如对于即时通讯系统，ServerGroup可能只负责指定账号号段的用户业务处理。每个ServerGroup都有自己的应用程序和数据库，但各ServerGroup的应用程序及数据库结构都是相同的，只是负责处理的业务范围不一样而已。随着业务的发展，ServerGroup的数量会逐步增加的。
在这种情形下，难以避免Global和ServerGroup之间以及ServerGroup和ServerGroup之间的通讯问题，因为Global的有些逻辑可能会访问ServerGroup中数据库的表，而ServerGroup的有些逻辑又需要访问Global或其他ServerGroup中数据库的表。对于这些Global及ServerGroup之间模块通讯方式，大致可采取如下三种方案：
方案一：全部采用Http/TCP等接口进行通讯
从架构图上可以看出：
Global中的模块并不直接方案ServerGroup中的数据库，而是采用通过ServerGroup中提供的“Group接口”进行访问。同样，ServerGroup中的模块也只是通过Global提供的“Global”接口进行方案，而不会直接连接Global中的数据库。
这么做的好处有：
a) 较好体现面向对象和分层的思想，Global和ServerGroup的内部底层处理逻辑对外透明，外界只通过接口进行访问，且接口是从业务级别进行定义的，并不关心内部访问了哪个数据库，操作了哪些表；
b) 有利于Global或Pool的内部后续改造，例如后续Global可能会进行“全局数据库”的切割或划分，由现在的一个库演变成多个库，或者以后会跨机房部署等；
但也有值得顾虑的地方：
a) 通过HTTP/TCP等接口的方式效率是否会较低？安全性和稳定性能否得到保障？
b) 对于特定的模块是否在开发上有一定困难，例如有些ServerGroup中的模块逻辑就适合在存储过程中实现，但存储过程中又需要访问处于Global数据库中的表；
c) 当Global和ServerGroup之间有表级别的数据需要同步时，传输的数据量有点大；
d) 以后Global和ServerGroup采用的数据库会发生变更怎么办？（由Oracle改为MySql）
方案二：数据库连接（DBLink）与HTTP/TCP接口相结合
当Global需要访问ServerGroup的逻辑时，仍通过ServerGroup提供的“Group接口”进行访问。但当ServerGroup需要访问Global中的数据时，就直接访问Global数据库。
由于整个系统中只有一个Global，故可以在每个ServerGroup数据库中建立访问Global数据库的连接（DBLink），这样在ServerGroup的模块中就能轻易访问Global数据库的表。
这么做开发上可能会简便一些，而且直接访问数据库可能效率和安全性稳定性上都有所提高。但总有点耦合得偏紧的感觉，可能不利于后续的维护和扩展。
方案三：全部采用直接方案数据库的方式
这是一种完全不采用接口通讯而直接访问数据库的方式。
同方案二，在每个ServerGroup的数据库中会创建对Global数据库的DBLink，ServerGroup中模块对Global数据的访问都直接通过DBLink的方式，和访问本地数据库没太大的差异。
在Global中也会存放各ServerGroup数据库的连接字符串（DB ConnectionString），当Global需要访问ServiceGroup的数据时，根据对应的数据库连接字符串直接连接到ServerGroup数据库进行表操作。
该方案所有通讯都是直接访问数据库的方式，效率可能会有进一步的提升，但耦合性更加紧密了。
对于这种分布式系统的模块通讯没太多的经验，有点不好取舍。全部采取接口的方式，可能看起来接口更加清晰，逻辑层次感强，屏蔽对数据层的操作，但HTTP/TCP等接口方式能否保证系统的正常运行？采用直接访问数据库的方式可能对于开发人员更直观，或许工作量小，风险小，局部看性能较高，但是否又违背了一些设计理念呢？
关于分布式系统架构模块通讯方式选择的问题相关推荐
- 整理下.net分布式系统架构的思路
最近看到有部分招聘信息,要求应聘者说一下分布式系统架构的思路.今天早晨正好有些时间,我也把我们实际在.net方面网站架构的演化路线整理一下,只是我自己的一些想法,欢迎大家批评指正. 首先说明的是.ne ...
- 分布式系统架构的基本原则和实践
采用分布式系统架构是由于业务需求决定的,若系统要求具备如下特性,便可考虑采用分布式架构来实现: 1.数据存储的分区容错,冗余 2.应用的大访问.高性能要求 3.应用的高可用要求,故障转移 分布式系统遵 ...
- 左耳朵耗子：聊聊分布式系统架构
点击关注 InfoQ,置顶公众号 程序员的 8 点技术早餐 作者|陈皓 编辑|杨爽 学习任何技术,善于提纲挈领总是事半功倍.学习分布式系统架构也是如此,只要找到这张网的纲,就能更有效率地做好架构和工程 ...
- 大型互联网分布式系统架构技术要点
大型互联网分布式系统架构技术要点 解决问题的通用思路是将分而治之(divide-and-conquer),将大问题分为若干个小问题,各个击破.在大型互联网的架构实践中,无一不体现这种思想. 架构目标 ...
- 八：对微服务通讯方式RPC vs REST的理解
微服务专栏地址 专栏:微服务 微服务系列总目录 目录 微服务专栏地址 目录 1. 简介 2. 关于RPC 2.1 什么是RPC 2.2 RPC有什么用 2.3 RPC的框架有哪些 2.3.1 服务治理 ...
- 【大型分布式网站】抗住千万流量的大型分布式系统架构设计
一.大型分布式网站架构技术 1.1 大型网站的特点 用户多,分布广泛 大流量,高并发 海量数据,服务高可用 安全环境恶劣,易受网络攻击 功能多,变更快,频繁发布 从小到大,渐进发展 以用户为中心 免费 ...
- 十年互联网架构师，带大家深入学习常见分布式系统架构，涨薪必备
常见分布式系统架构 复杂的大型软件系统,倾向于使用分布式系统架构.就像Warren Buffett有个关于投资的名言,就是"不要把鸡蛋放在一个篮子里".对于系统而言也是如此.厂商的 ...
- 从Elasticsearch来看分布式系统架构设计，真是666~
欢迎关注方志朋的博客,回复"666"获面试宝典 分布式系统类型多,涉及面非常广,不同类型的系统有不同的特点,批量计算和实时计算就差别非常大.这篇文章中,重点会讨论下分布式数据系统的 ...
- 分布式系统架构与云原生—阿里云《云原生架构白皮书》导读
-点击领取<云原生架构白皮书>- 导语: 有幸作为阿里云MVP提前获得了阿里云云原生团队编写的<云原生架构白皮书>,希望通过自己对于云原生的理解为开发者提供一篇观后感或者是能够 ...
最新文章
- 计算机专业申请,申请计算机专业
- 转：深入理解Java G1垃圾收集器
- x64dbg 搜索多条指令 ( find sequence of commands )
- springboo整合security——权限设置
- VS2010-MFC（文档、视图和框架：分割窗口）
- IDE-Ecplise-代码注释 模版 编码规范 配色
- excel在线_功能强大的纯前端 Excel 在线表格： Luckysheet
- java io 机器名_java IO最让初学者误解的取名方式
- windows下ch340 usb转串口芯片的驱动从哪里下载？
- java keytool详解
- 移动开发平台-应用之星app制作教程
- 十问：BAT技术大牛的核心学习方法
- Spring AOP基础组件 Advised
- 对象、继承、封装、多态、抽象类的组合应用：编写工资系统，实现不同类型员工(多态)的按月发放工资。如果当月出现某个Employee对象的生日，则将在该雇员的工资上增加100元发给他。
- [免费专栏] Android安全之Android Xposed插件开发，小白都能看得懂的教程
- 【第五课】UAV倾斜摄影测量三维建模之空三计算问题
- IE6，IE7和FireFox兼容处理（持续发现中）
- HICO/HICO-Det 数据集介绍
- 外贸公司报价/换汇成本计算公式
- 天气数据采集微服务的实现：数据采集组件、数据存储组件