简介
作为一名架构师, 我们要专业, 要能看懂代码, 及时光着臂膀去机房, 也能独挡一面! 及时同事搞不定问题, 或者撂挑子, 你也能给老大一个坚定的眼神: 不怕, 有我在! 还能在会议室上滔滔不绝, 如若无人, 让不懂技术的妹子看你时眼神迷离, 就好想落霞与孤鹜齐飞!
分布式架构是一个非常复杂的体系, 任何技术都不是孤立的存在, 任何技术都无法适应所有场景. 作为一名分布式系统架构或者资深研发人员, 我们必须尽可能多的学习与之相关的各种知识, 掌握各种技术的演进路线, 正式从一名码农蜕变成为架构师
什么是分布式?
互联网应用的特点是: 高并发, 海量数据. 互联网应用的用户数是没有上限的(取决于其开放特性), 这也是和传统应用的本质区别. 高并发指系统单位时间内收到的请求数量(取决于使用的用户数), 没有上限. 海量数据包括: 海量数据的存储和海量数据的处理. 这两个工程难题都可以使用分布式系统来解决.
简单理解, 分布式系统就是把一些计算机通过网络连接起来, 然后协同工作. 协同工作需要解决两个问题:
1)任务分解
把一个问题拆解成若干个独立任务, 每个任务在一台节点上运行, 实现多任务的并发执行.
2)节点通信
节点之间互相通信, 需要设计特定的通信协议来实现. 协议可以采用 RPC 或 Message Queue 等方式.
分布式和集群的关系
分布式: 一个业务分拆多个子业务, 部署在不同的服务器上
集群: 同一个业务, 部署在多个服务器上
计算机发展历史
1946 年情人节(2.14) , 世界上第一台电子数字计算机诞生在美国宾夕法尼亚大学大学, 它的名字是: ENIAC; 这台计算机占地 170 平米, 重达 30 吨, 每秒可进行 5000 次加法运算.
第一台电子计算机诞生以后, 意味着一个日新月异的 IT 时代的到来. 一方面单台计算机的性能每年都在提升: 从最早的 8 位 CPU 到现在的 64 位 CPU; 从早期的 MB 级内存到现在的 GB 级别内存; 从慢速的机械存储到现在的固态 SSD 硬盘存储.
|
tips: 电子计算机的问世, 最重要的奠基人是英国科学家艾兰. 图灵 (Alan Turing) 和美籍匈牙利科学家冯. 诺依曼(John Von. Neumann). 图灵的贡献是建立了图灵机的理论模型, 奠定了人工智能的基础. 而冯. 诺依曼则是首先提出了计算机体系结构的设想.
经典理论 - 冯. 诺依曼体系: 计算机硬件由运算器, 控制器, 存储器, 输入设备, 输出设备五大部分组成. 直到今天, 计算机仍没有跳出该体系的范畴.
ENIAC 之后, 电子计算机便进入了 IBM 主导的大型机时代, IBM 大型机之父吉恩. 阿姆达尔被认为是有史以来最伟大的计算机设计师之一. 1964 年 4 月 7 日, 在阿姆达尔的带领下, 历时三年, 耗费 50 亿美元, 第一台 IBM 大型机 SYSTEM/360 诞生. 这使得 IBM 在 20 实际 50~60 年代统治整个大型计算机工业, 奠定了 IBM 计算机帝国的江山.
2.1 IBM 大型机曾支撑美国航天登月计划
2.2 IBM 主机一直服务于金融等核心行业的关键领域
由于高可靠性和超强的计算能力, 几遍在 X86 和云计算飞速发展的情况下, IBM 的大型机依然牢牢占据着一定的高端市场份额
20 世纪 80 年代, 在大型机霸主的时代, 计算机架构同时向两个方向发展
以 X86 CPU 为架构的价格便宜的面向个人的 PC
以 RISC CPU 为架构的价格昂贵的面向企业的小型 UNIX 服务器
分布式架构发展的里程碑
大型主机的出现. 凭借着大型机超强的计算和 I/O 处理能力, 稳定性, 安全性等, 在很长一段时间内, 大型机引领了计算机行业及商业计算领域的发展.
而集中式的计算机系统架构也成为了主流.
随着计算机的发展, 这种架构越来越难以适应人们的需求, 比如说
由于大型主机的复杂性, 导致培养一个能够熟练运维大型主机的人的成本很高
大型主机很贵, 一般只有土豪 (政府, 金融, 电信) 才能用得起
单点问题, 一台大型主机出现故障, 那么整个系统将处于不可用状态. 而对于大型机的使用群体来说, 这种不可用导致的损失是非常大的
科技在进步, 技术在进步. PC 机性能不断提升, 很多企业放弃大型机改用小型机及普通 PC 来搭建系统架构
什么是分布式架构
分布式系统(distributed system) 是建立在网络之上的软件系统.
内聚性: 是指每一个数据库分布节点高度自治, 有本地的数据库管理系统.
透明性: 是指每一个数据库分布节点对用户的应用来说都是透明的, 看不出是本地还是远程.
分布式架构的应用
1, 分布式文件系统
例如: 出名的有 Hadoop 的 HDFS, 还有 google 的 GFS , 淘宝的 TFS 等
2, 分布式缓存系统
例如: memcache , hbase, mongdb 等
3, 分布式数据库
例如: MySQL, mariadb, PostgreSQL 等
4, 分布式 webService
5, 分布式计算
阿里巴巴在 2009 年发起了一项 "去 IOE" 运动
当初指的是 IBM 小型机, Oracle 数据库, EMC 的高端存储
2009 年 "去 IOE" 战略透露, 到 2013 年 5 月 17 日最后一台 IBM 小型机在支付宝下线.
为什么要去 IOE?
阿里巴巴过去一直采用的是 Oracle 数据库, 并利用小型机和高端存储设备提供高性能的数据处理和存储服务. 随着业务的不断发展, 数据量和业务量呈爆发性增长, 传统的集中式 Oracle 数据库架构在扩展性方面遭遇瓶颈.
传统的商业数据库软件 (Oracle,DB2), 多以集中式架构为主, 这些传统数据库软件的最大特点就是将所有的数据都集中在一个数据库中, 依靠大型高端设备来提供高处理能力和扩展性. 集中式数据库的扩展性主要采用向上扩展(Scale up) 的方式, 通过增加 CPU, 内存, 磁盘等方式提高处理能力. 这种集中式数据库的架构, 使得数据库成为了整个系统的瓶颈, 已经越来越不适应海量数据对计算能力的巨大需求
架构的发展演变过程
一个成熟的大型网站系统架构并不是一开始就设计的非常完美, 也不是一开始就具备高性能, 高可用, 安全性等特性, 而是随着用户量的增加, 业务功能的扩展逐步完善演变过来的. 在这个过程中, 开发模式, 技术架构等都会发生非常大的变化. 而针对不同业务特征的系统, 会有各自的侧重点, 比如像淘宝这类的网站, 要解决的是海量商品搜索, 下单, 支付等问题; 像腾讯, 要解决的是数亿级别用户的实时消息传输; 百度所要解决的是海量数据的搜索. 每一个种类的业务都有自己不同的系统架构. 我们简单模拟一个架构演变过程.
什么是大型网站
如何定义一个网站是不是大型网站, 一般我们会从两个纬度去考衡, 访问量以及数据量, 二者缺一不可.
我们以 javaweb 为例, 来搭建一个简单的电商系统, 从这个系统中来看系统的演变历史; 要注意的是, 接下来的演示模型, 关注的是数据量, 访问量提升, 网站结构发生的变化, 而不是具体关注业务功能点. 其次, 这个过程是为了让大家更好的了解网站演进过程中的一些问题和应对策略.
假如我们系统具备以下功能:
用户模块: 用户注册和管理
商品模块: 商品展示和管理
交易模块: 创建交易及支付结算
阶段一 , 单应用架构
网站的初期也可以认为是互联网发展的早起, 我们经常会在单机上跑我们所有的程序和软件.
把所有软件和应用都部署在一台机器上, 这样就完成一个简单系统的搭建, 这个时候的讲究的是效率
阶段二, 应用服务器和数据库服务器分离
随着网站的上线, 访问量逐步上升, 服务器的负载慢慢提高, 在服务器还没有超载的时候, 我们应该做好规划, 提升网站的负载能力. 假如代码层面的优化已经没办法继续提高, 在不提高单台机器的性能, 增加机器是一个比较好的方式, 投入产出比非常高. 这个阶段增加机器的主要目的是讲 Web 服务器和数据库服务器拆分, 这样不仅提高了单机的负载能力, 也提高了容灾能力
阶段三, 应用服务器集群 - 应用服务器负载告警, 如何让应用服务器走向集群
随着访问量的继续增加, 单台应用服务器已经无法满足需求. 在假设数据库服务器还没有遇到性能问题的时候, 我们可以增加应用服务器, 通过应用服务器集群将用户请求分流到各个服务器中, 从而继续提升负载能力. 此时多台应用服务器之间没有直接的交互, 他们都是依赖数据库各自对外提供服务
架构发展到这个阶段, 各种问题也会慢慢呈现
用户请求由谁来转发到具体的应用服务器
用户如果每次访问到的服务器不一样, 那么如何维护 session
阶段四, 数据库压力变大, 数据库读写分离
架构演变到这里, 并不是终点. 上面我们把应用层的性能拉上来了, 但是数据库的负载也在慢慢增大, 那么怎么去提高数据库层面的负载呢? 有了前面的思路以后, 自然会想到增加服务器. 但是假如我们单纯的把数据库一分为二, 然后对于后续数据库的请求, 分别负载到两台数据库服务器上, 那么一定会造成数据库不统一的问题. 所以我们一般先考虑读写分离的方式
这个架构的变化会带来几个问题
主从数据库之间的数据同步 ; 可以使用 MySQL 自带的 master-slave 方式实现主从复制
对应数据源的选择 ; 采用第三方数据库中间件, 例如 mycat
阶段五, 使用搜索引擎缓解读库的压力
数据库做读库的话, 尝尝对模糊查找效率不是特别好, 像电商类的网站, 搜索是非常核心的功能, 即便是做了读写分离, 这个问题也不能有效解决. 那么这个时候就需要引入搜索引擎了
使用搜索引擎能够大大提高我们的查询速度, 但是同时也会带来一些附加的问题, 比如维护索引的构建.
阶段六, 引入缓存机制缓解数据库的压力
随着访问量的持续增加, 逐渐出现许多用户访问统一部分内容的情况, 对于这些热点数据, 没必要每次都从数据库去读取, 我们可以使用缓存技术, 比如 memcache,Redis 来作为我们应用层的缓存; 另外在某些场景下, 比如我们对用户的某些 IP 的访问频率做限制, 那这个放内存中又不合适, 放数据库又太麻烦, 这个时候可以使用 Nosql 的方式比如 mongDB 来代替传统的关系型数据库
阶段七, 数据库的水平 / 垂直拆分
我们的网站演进的变化过程, 交易, 商品, 用户的数据都还在同一个数据库中, 尽管采取了增加缓存, 读写分离的方式, 但是随着数据库的压力持续增加, 数据库的瓶颈仍然是个最大的问题. 因此我们可以考虑对数据的垂直拆分和水平拆分
垂直拆分: 把数据库中不同业务数据拆分到不同的数据库
水平拆分: 把同一个表中的数据拆分到两个甚至跟多的数据库中, 水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈, 这时可以采取讲表拆分到多个数据库中
阶段八, 应用的拆分
随着业务的发展, 业务越来越多, 应用的压力越来越大. 工程规模也越来越庞大. 这个时候就可以考虑讲应用拆分, 按照领域模型讲我们的用户, 商品, 交易拆分成多个子系统
这样拆分以后, 可能会有一些相同的代码, 比如用户操作, 在商品和交易都需要查询, 所以会导致每个系统都会有用户查询访问相关操作. 这些相同的操作一定是要抽象出来, 否则就会是一个坑. 所以通过走服务化路线的方式来解决
那么服务拆分以后, 各个服务之间如何进行远程通信呢?
通过 RPC 技术, 比较典型的有: webservice,hessian,http,RMI 等等
前期通过这些技术能够很好的解决各个服务之间通信问题, but, 互联网的发展是持续的, 所以架构的演变和优化还在持续.
总结
我们通过这个例子来讲解了电商网站的架构演进. 我要强调一下, 这个架构的演进不是某个网站真实的例子, 实际上是通过这样一个演进过程给大家带来一个全局的观念和感受. 以及给大家在后续课程学习过程中的一些思路.
如何把单击扩展到分布式
前面我们讲到了冯. 诺依曼模型, 计算机一共由 5 个部分组成, 从用户角度来看, 分布式系统就像一台超级计算机. 理论上也应该由输入, 输出, 运算, 存储和控制这 5 部分组成.
输入设备的变化
在分布式系统架构中, 输入设备可以分两类, 第一类是互相连接的多个节点, 在接收其他节点传来的信息作为该节点的输入; 另一种就是传统意义上的人机交互的输入设备了
输出设备的变化
输出和输入类似, 也有两种, 一种是系统中的节点向其他节点传输信息时, 该节点可以看作是输出设备; 另一种就是传统意义上的人际交互的输出设备, 比如用户的终端
控制器的变化
在单机中, 控制器指的是 CPU 中的控制器, 在分布式系统中, 控制器主要的作用是协调或控制节点之间的动作和行为; 比如硬件负载均衡器; LVS 软负载; 规则服务器等
运算器
在分布式系统中, 运算器是由多个节点来组成的. 运用多个节点的计算能力来协同完成整体的计算任务
存储器
在分布式系统中, 我们需要把承担存储功能的多个节点组织在一起, 组成一个整体的存储器; 比如数据库, Redis(key-value 存储)
来源: http://www.jianshu.com/p/48a086097fee