架构师的学习可从如下几个方面着手:
第一、基础方面:包括数据结构、操作系统、算法应用、设计模式等一切拥有优秀编程能力
所应该熟知的软件基础知识;
第二、技术方面:如何使用优秀的技术产品去构建自己的系统,这些技术产品各自的特点是
什么,有什么优缺点、具体原理是怎样的?都要有深刻掌握和理解。对大型互联网系统而言,
主要包括缓存、异步、分布式存储、微服务等;
第三、架构方面:考虑点主要包括高可用、高性能、高扩展这三部分。
总之,作为一名技术人,我们既然选择了这个职业,就一定要有上进的决心,不能只顾写代
码,一定要提升架构设计能力。因为即使代码写得再好,做的也是执行层面的事儿,就会有
收入的天花板,想要突破它,就要突破你做事儿的边界,让自己成为一个架构师或技术负责
人。
分布式
什么是分布式架构?
当系统的并发处理能力,存储能力等不足时,我们可能会创建多个
Web
服务
(
多个
tomcat
服务器
),
多个数据库服务
(
主动架构等
)
,这些服务器通过网络进行连接,然后协同处理客
户端的并发请求,这样的系统我们称之为分布式系统。(这里要说明的一点是微服务架构是
分布式架构,但分布式架构不一定是微服务架构)例如:
为什么需要分布式架构?
当一个系统的业务
量
越来越大时,我们需要垂直或是水平拆分业务系统,同时为了避免所有
业务都部署在一台机器上时,一旦机器出现故障从而导致整体不可用,就需要将这些业务部
署在多台计算机上,来构建一个分布式架构。
分布式架构可以更好的提高系统的容量、可靠性(避免单点故障)、性能
。同时因为模块化,
系统的可重用性以及并行开发的效率也会提高。
分布式架构有哪些优势?
1.
可以实现更大数据量的存储。(字节跳动每天几十个
PB
的数据)
2.
可以更好提高系统的高可用性。(业务冗余、业务拆分、限流、降级
….
)
3.
可以更好提高系统的可重用性。
(
公共模块
-
例如订单系统、支付系统,日志收集系统,
监控系统,。。。
)
4.
可以更好提高系统的性能。(并行处理能力)
分布式架构有什么劣势?
分布式系统架构虽然解决
了
“单点”、“性能”和”容
量
“的问题,但却新增
了
一些新的问题。
①会增加架构设计的难度。
②部署和维护的成本也会加大。
很多技术方案都是“按下葫芦浮起瓢”,都是有得有失,分布式架构也是如此,理性面对即
可。
分布式架构有哪些关键技术?
服务治
理
。
服务治
理
的最大意义是需要把服务间的依赖关系、服务调用链,以及关键的服务给梳
理
出来,
并对这些服务进
行
性能和可用性方面的管
理
。
架构管
理
。
基于服务所形成的架构需要有架构版本管
理
、整体架构的生命周期管
理
,以及对服务的编排、
聚合、事务处
理
等服务调度功能。
DevOps
。
分布式系统可以
更
为快速地
更
新服务,但是对于服务的测试和部署都会是挑战。所以,还需
要
DevOps
的全流程,其中包括环境构建、持续集成、持续部署等。自动化运维。有
了
DevOps
后,我们就可以对服务进
行
自动伸缩、故障迁移、配置管
理
、状态管
理
等 一系
列
的自动化
运维技术
了
。
资源调度管
理
。
应用层的自动化运维需要基础层的调度支持,也就是云计算
IaaS
层的计算、存储、网络等
资源调度、隔离和管
理
。
整体架构监控。
如果没有一个好的监控系统,那么自动化运维和资源调度管
理
只可能成为一个泡影, 因为
监控系统是你的眼睛。没有眼睛,没有数据,就无法进
行
高效的运维。所以说,监控是非常
重要 的部分。这
里
的监控需要对三层系统(应用层、中间件层、基础层)进
行
监控。
流
量
控制。
我们的流
量
控制,负载均衡、服务
路
由、熔断、降级、限流等和流
量
相关的调度都 会在这
里
,包括灰度发布之类的功能也在这
里
。
基于分布式架构如何提高其高性能?
一般面对这样的问题,从整体维度去思考时,通常要分析问题,例如影响系统性能的因素有
哪些?
1)
请求数据传输时间
2)
请求数据的处理时间
3)
响应数据的传输时间
4)
响应数据的渲染时间 (
json->html/css/js
)
解决方案如下:
1)
减少数据传输时间?
(
加带宽,减少数据传输量,减少传输距离,数据压缩
)
2)
提高请求数据的处理速度?
(
分布式架构,缓存,算法,
sql
调优,索引的设计,异步,
硬件
)
3)
提高数据在客户端的渲染时间?
(
局部更新,减少不必要的元素等
)
具体从架构层面进行设计的话可以从如下几个维度进行思考:
应用缓存。
为系统添加缓存,可以有效地提高系统的访问能
力
。从前端的浏览
器
,到网络,再到后端的
服务,底层的数据库、文件系统、硬盘和
CPU
,全都有缓存,这是提高快速访问能
力
最有效
的手段。
负载均衡。
负载均衡是做水平扩展的关键技术,我们可以使用多台机
器
来共同分担一部分流
量
请求。
异步调用。
异步系统主要通过消息队
列
来对请求做排队处
理
,这样可以把前端的请求的峰值给“削平”
了
,而后端通过自己能够处
理
的速度来处
理
请求。
数据分区和数据镜像
数据分区是把数据按一定的方式分成多个区(比如通过地
理
位置),
不
同的数据区来分担
不
同区的流
量
如何基于架构提高系统的稳定性?
服务拆分。
服务拆分可以更好的实现故障隔离,同时也可以重用服务模块。
服务冗余。
服务冗余是为了去除单点故障,支持服务的弹性伸缩,以及故障迁移。
限流降级。
当系统扛
不
住压
力
时,只能通过限流或者功能降级的方式来停掉一部
分服务,或是拒绝一部分用户,以确保整个架构
不
会挂掉。
高可用架构。
高可用就是从冗余架构的角度来保障可用性。比如多租户隔离,灾备
多活等。总之,就是为
了不
出单点故障。
高可用运维。
指的是 DevOps 中的 CI(持续集成)/CD(持续部署)。一个良
好的运维应做
了
足够的自动化测试,做了相应的灰度发布,以及对线
上系统的自动化控制。这样,可以做到“计划内”或是“非计划内”的宕机
事件的时长最短。
分布式架构有什么难点?
异构系统存在很多不标准问题。
构建软件时使用的编程语言、通讯协议、数据格式、运维标准可能不同,进而导致架构设计
的复杂度越来越高。
系统架构中的服务依赖问题。
传统的单体应用,一台机器挂了,整个软件就挂掉了,分布式架构下也可能会出现这样的问
题,因为一个服务可能会依赖于另一个服务,某个服务挂掉了,会导致调用链上的服务都出
现故障(这就是多米诺骨牌效应)
故障发生的概率更大。
分布式系统中,服务和机器都会比较多,故障发生的频率会更大,只是影响面没有单体应用
的影响面大,分布式系统中故障可以被隔离。还有就是分布式架构管理相对于单体架构也更
加复杂,没有优秀的架构管理人员,故障的频率还是会非常高。
多层架构的运维复杂度更大。
分布式架构中,我们可以将系统分为四层
(
基础层、平台层、应用层、接入层
)
。
1)
基础层
:
包括机器、网络和存储设备。
2)
平台层
:
就是中间件层包括
tomcat
、
MySQL
、
Redis
、
Kafka
类似的软件。
3)
应用层
:
就是我们的业务软件,包括各种业务服务。
4)
接入层
:
就是接入用户请求的网关、负载均衡、
CDN
、
DNS
等。