https://cloud.tencent.com/info/e9695bd18d1c7752b3924bb3ac38cc95.html

【51CTO技术沙龙】10月27日,让我们共同探索AI场景化应用实现之道 –>

云架构师负责管理一个组织中的云计算架构,特别是随着云技术日益复杂化。云计算架构涵盖了与云计算相关的一切,包括管理云存储所需的前端平台、服务器、存储、交付和网络。

本文作者从如下几个方面全面剖析云架构师的进阶攻略:

  • 架构的三个维度和六个层面
  • 了解云计算的历史演进与基本原理
  • 开源软件是进阶的利器
  • 了解 Linux 基础知识
  • 了解数据中心和网络基础知识
  • 基于 KVM 了解计算虚拟化
  • 基于 Openvswitch 了解网络虚拟化
  • 基于 OpenStack 了解云平台
  • 基于 Mesos 和 Kubernetes 了解容器平台
  • 基于 Hadoop 和 Spark 了解大数据平台
  • 基于 Lucene 和 ElasticSearch 了解搜索引擎
  • 基于 Spring Cloud 了解微服务

架构的三个维度和六个层面

三个维度

在互联网时代,要做好一个合格的云架构师,需要熟悉三大架构。

IT 架构

IT 架构其实就是计算,网络,存储。这是云架构师的基本功,也是最传统的云架构师应该首先掌握的部分。

良好设计的 IT 架构,可以降低 CAPEX 和 OPEX,减轻运维的负担。数据中心,虚拟化,云平台,容器平台都属于 IT 架构的范畴。

应用架构

随着应用从传统应用向互联网应用转型,仅仅搞定资源层面的弹性还不够,常常会出现创建了大批机器,仍然撑不住高并发流量。因而基于微服务的互联网架构,越来越成为云架构师所必需的技能。

良好设计的应用架构,可以实现快速迭代和高并发。数据库,缓存,消息队列等 PaaS,以及基于 Spring Cloud 和 Dubbo 的微服务框架,都属于应用架构的范畴。

数据架构

数据成为人工智能时代的核心资产,在做互联网化转型的同时,往往进行的也是数字化转型,并有战略的进行数据收集,这就需要云架构师同时有大数据思维。

有意识的建设统一的数据平台,并给予数据进行数字化运营。搜索引擎,Hadoop,Spark,人工智能都属于数据架构的范畴。

六个层面

上面的三个维度是从人的角度出发的,如果从系统的角度出发,架构分六个层次。

基础设施层

在数据中心里面,会有大量的机架,大量的服务器,并通过交换机和路由器将服务器连接起来,有的应用例如 Oracle 是需要部署在物理机上的。

为了管理的方便,在物理机之上会部署虚拟化,例如 Vmware,可以将对于物理机复杂的运维简化为虚拟机灵活的运维。

虚拟化采取的运维方式多是由运维部门统一管理,当一个公司里面部门非常多的时候,往往要引入良好的租户管理。

基于 Quota 和 QoS 的资源控制,基于 VPC 的网络规划等,实现从运维集中管理到租户自助使用模式的转换,托生于公有云的 OpenStack 在这方面做的是比较好的。

随着应用架构越来越重要,对于标准化交付和弹性伸缩的需求越来越大,容器做为软件交付的集装箱,可以实现基于镜像的跨环境迁移,Kubernetes 是容器管理平台的事实标准。

数据层

数据层,也即一个应用的中军大营,如果是传统应用,可能会使用 Oracle,并使用大量的存储过程,有大量的表联合查询,成本也往往比较高。

但是对于高并发的互联网应用,需要进行微服务的拆分,数据库实例会比较多,使用开源的 MySQL 是常见的选择。

大量的存储过程和联合查询往往会使得微服务无法拆分,性能会比较差,因而需要放到应用层去做复杂的业务逻辑,而且数据库表和索引的设计非常重要。

当并发量比较大的时候,需要实现横向扩展,就需要基于分布式数据库,也是需要基于单库良好的表和索引设计。

对于结构比较灵活的数据,可以使用 MongoDB 数据库,横向扩展能力比较好。

对于大量的联合查询需求,可以使用 ElasticSearch 之类的搜索引擎来做,速度快,更加灵活。

中间件层

因为数据库层往往需要保证数据的不丢失以及一些事务,因而并发性能不可能非常大。

所以我们经常说,数据库是中军大营,不能所有的请求都到这里来,因而需要一层缓存层,用来拦截大部分的热点请求。

Memcached 适合做简单的 key-value 存储,内存使用率比较高,而且由于是多核处理,对于比较大的数据,性能较好。

但是缺点也比较明显,Memcached 严格来讲没有集群机制,横向扩展完全靠客户端来实现。

另外 Memcached 无法持久化,一旦挂了数据就都丢失了,如果想实现高可用,也是需要客户端进行双写才可以。

Redis 的数据结构比较丰富,提供持久化的功能,提供成熟的主备同步,故障切换的功能,从而保证了高可用性。

另外微服务拆分以后,有时候处理一个订单要经过非常多的服务,处理过程会比较慢,这个时候需要使用消息队列,让服务之间的调用变成对于消息的订阅,实现异步处理。

RabbitMQ 和 Kafka 是常用的消息队列,当事件比较重要的时候,会结合数据库实现可靠消息队列。

基础服务层

有的时候成为中台层,将通用的能力抽象为服务对外提供原子化接口。

这样上层可以根据业务需求,通过灵活的组合这些原子化接口,灵活的应对业务需求的变化,实现能力的复用,以及数据的统一管理,例如用户数据,支付数据,不会分散到各个应用中。

另外基础服务层称为应用、数据库和缓存的一个分界线,不应该所有的应用都直接连数据库,一旦出现分库分表,数据库迁移,缓存选型改变等,影响面会非常大,几乎无法执行。

如果将这些底层的变更拦截在基础服务层,上层仅仅使用基础服务层的接口,这样底层的变化会对上层透明,可以逐步演进。

业务服务层或者组合服务层

大部分的业务逻辑都是在这个层面实现,业务逻辑比较面向用户,因而会经常改变,所以需要组合基础服务的接口进行实现。

在这一层,会经常进行服务的拆分,实现开发独立,上线独立,扩容独立,容灾降级独立。

微服务的拆分不应该是一个运动,而应该是一个遇到耦合痛点的时候,不断解决,不断演进的一个过程。

微服务拆分之后,有时候需要通过分布式事务,保证多个操作的原子性,也是在组合服务层来实现的。

用户接口层

用户接口层,也即对终端客户呈现出来的界面和 App,但是却不仅仅是界面这么简单。

这一层有时候称为接入层。在这一层,动态资源和静态资源应该分离,静态资源应该在接入层做缓存,使用 CDN 进行缓存。

也应该 UI 和 API 分离,界面应该通过组合 API 进行数据拼装。API 会通过统一的 API 网关进行统一的管理和治理。

一方面后端组合服务层的拆分对 APP 是透明的;另一方面当并发量比较大的时候,可以在这一层实现限流和降级。

为了支撑这六个层次,在上图的左侧是一些公共能力:

  • 持续集成和持续发布是保证微服务拆分过程中的快速迭代,以及变更后保证功能不变的,不引入新的 Bug。
  • 服务发现和服务治理是微服务之间互相的调用,以及调用过程中出现异常情况下的熔断,限流,降级策略。
  • 大数据和人工智能是通过收集各个层面的数据,例如用户访问数据,用户下单数据,客服询问数据等,结合统一的中台,对数据进行分析,实现智能推荐
  • 监控与 APM 是基础设施的监控和应用的监控,发现资源层面的问题以及应用调用的问题。

作为一个云架构师还是很复杂的,千里之行,始于足下,让我们慢慢来。

了解云计算的历史演进与基本原理

在一头扎进云计算的汪洋大海之前,我们应该先有一个全貌的了解,有人说了解一个知识的起点,就是了解它的历史,也就是知道它是如何一步一步到今天的,这样如此庞大的一个体系,其实是逐步加进来的。

这样的知识体系对我们来说,就不是一个冷冰冰的知识网,而是一个有血有肉的人,我们只要沿着演进的线索,一步一步摸清楚“它”的脾气就可以了。

如何把云计算讲的通俗易懂,我本人思考了半天,最终写下了下面这篇文章:终于有人把云计算、大数据和人工智能讲明白了!在这里,我把核心的要点在这里写一下。

第一:云计算的本质是实现从资源到架构的全面弹性。

所谓的弹性就是时间灵活性和空间灵活性,也即想什么时候要就什么时候要,想要多少就要多少。

资源层面的弹性也即实现计算、网络、存储资源的弹性。这个过程经历了从物理机,到虚拟化,到云计算的一个演进过程。

架构层面的弹性也即实现通用应用和自有应用的弹性扩展。对于通用的应用,多集成为 PaaS 平台。

对于自己的应用,通过基于脚本的 Puppet、Chef、Ansible 到基于容器镜像的容器平台 CaaS。

第二:大数据包含数据的收集,数据的传输,数据的存储,数据的处理和分析,数据的检索和挖掘等几个过程。

当数据量很小时,很少的几台机器就能解决。慢慢的,当数据量越来越大,最牛的服务器都解决不了问题时,怎么办呢?

这时就要聚合多台机器的力量,大家齐心协力一起把这个事搞定,众人拾柴火焰高。

第三:人工智能经历了基于专家系统的计划经济,基于统计的宏观调控,基于神经网络的微观经济学三个阶段。

开源软件是进阶的利器

架构师除了要掌握大的架构和理论之外,指导落地也是必备的技能,所谓既要懂设计模式,也要懂代码。那从哪里去学习这些良好的,有借鉴意义的,可以落地的架构实践呢?

这个世界上还是有很多有情怀的大牛的,尤其是程序员里面,他们喜欢做一件什么事情呢?答案是开源。很多软件都是有闭源就有开源,源就是源代码。

当某个软件做的好,所有人都爱用,这个软件的代码呢,我封闭起来只有我公司知道,其他人不知道,如果其他人想用这个软件,就要付我钱,这就叫闭源。但是世界上总有一些大牛看不惯钱都让一家赚了去。

大牛们觉得,这个技术你会我也会,你能开发出来,我也能,我开发出来就是不收钱,把代码拿出来分享给大家,全世界谁用都可以,所有的人都可以享受到好处,这个叫做开源。

非常建议大家了解,深入研究,甚至参与贡献开源软件,因为收益匪浅。

第一:通过开源软件,我们可以了解大牛们的架构原则,设计模式。

其实咱们平时的工作中,是很难碰到大牛的,他可能是你渴望而不可及的公司的员工,甚至在国外,你要想进这种公司,不刷个几年题目,面试个 N 轮是进不去的。

即便进去了,他可能是公司的高层,每天很忙,不怎么见得到他,就算当面讨教,时间也不会很长,很难深入交流。

也有的大牛会选择自主创业,或者是自由职业者,神龙见首不见尾,到了大公司都见不到。

但是感谢互联网和开源社区,将大牛们拉到了我们身边,你可以订阅邮件组,可以加入讨论群,可以看到大牛们的设计,看到很多人的评论,提问,还有大牛的回答,可以看到大牛的设计也不是一蹴而就完美的,看到逐渐演进的过程,等等。

这些都是能够帮助我们快速提升水平的地方,有的时候,拿到一篇设计,都要查资料看半天,一开始都可能好多的术语都看不懂,没关系肯下功夫,当你看 blueprints 越来越顺畅的时候,你就进步了。

第二:通过开源软件,我们可以学习到代码级的落地实践。

有时候我们能看到很多大牛写的书和文章,也能看到很多理论的书籍,但是存在一个问题是,理论都懂,但是还是做不好架构。

这是因为没有看到代码,所有的理论都是空中楼阁,当你到了具体的代码设计层面,那些学会的设计模式,无法转化为你自己的实践。

好在开源软件的代码都是公开的,凝结了大牛的心血,也能够看到大牛在具体落地时候的取舍,一切那么真实,看得见,摸得着。

通过代码进行学习,配合理论知识,更容易获得第一手的经验,并且在自己做设计和写代码的时候,马上能够映射到可以参考的场景,让我们在做自己的系统的时候,少走弯路。

第三:通过开源软件,我们可以加入社区,和其他技术人员在同一背景下共同进步。

大牛我们往往不容易接触到,正面讨论技术问题的时间更是难能可贵,但是没有关系,开源软件构建了一个社区,大家可以在一起讨论。

你是怎么理解的,别人是怎么理解的,越讨论越交流,越明晰,有时候和比你经验稍微丰富一点的技术人员交流,可能比直接和大牛对话更加有直接作用。

大牛的话可能让你消化半天,依然不知所云,大牛可能觉得很多普通人觉得的难点是显而易见的,不屑去解释。

但是社区里面的技术人员,可能和你一样慢慢进步过来的,知道哪些点是当年自己困惑的,如果踩过这一个个的坑,他们一点拨,你就会豁然开朗。

而且每个人遇到的具体情况不同,从事的行业不同,客户的需求不同,因而软件设计的时候考虑的因素不同。

大牛是牛,但是不一定能够遇到和你一样的场景,但是社区里面,有你的同行业的,背景相近的技术人员,你们可以讨论出符合你们特定场景的解决方案。

第四:通过开源软件,我们作为个人,比较容易找到工作。

我们面试的时候,常常遇到的问题是,怎么能够把在原来工作中自己的贡献,理解,设计,技术能力展现出来。

其实我发现很多程序员不能很好的做到这一点,所以造成很多人面试很吃亏。

原因之一:背景信息不对称。例如原来面临的业务上很难的问题,面试官由于不理解背景,而且短时间解释不清楚,轻视候选人的水平。

我也遇到过很多面试官才听了几分钟,就会说,这不挺简单的,你这样这样不就行了,然后彻底否定你们一个团队忙了三年的事情。

原因之二:很多有能力的程序员不会表达,导致真正写代码的说不明白。可能原来在公司里面一个绩效非常好,一个绩效非常差,但是到了面试官那里就拉平了。

原因之三:新的公司不能确定你在上家公司做的工作,到这一家都能用的。例如你做的工作有 30% 是和具体业务场景相关的,70% 是通用技术,可能下家公司只会为你的通用技术部分买单。

开源软件的好处就是,参与的人所掌握的技能都是通的,而且大家在同一个上下文里面对话,面试官和候选人之间的信息差比较少。掌握某个开源软件有多难,不用候选人自己说,大家心里都有数。

对于很多技术能力强,但是表达能力较弱的极少数人员来讲,talk is cheap,show me the code。

代码呈上去,就能够表现出实力来了,而且面试官也不需要根据短短的半个小时了解一个人,可以做很多背景调查。

另外由于掌握的技术是通用的,你到下一家公司,马上就能够上手,几乎不需要预热时间,对于双方都有好处。

第五:通过开源软件,我们作为招聘方,比较容易招到相应人员。

如果在创业公司待过的朋友会了解到创业公司招人很难,人员流失很快,而且创业公司往往对于开发进度要求很快,因为大家都在抢时间。

因而开源软件对于招聘方来讲,也是好消息。首先创业公司没办法像大公司一样,弄这么多的技术大牛,自己完全落地一套自己的体系,使用开源软件快速搭建一套平台先上线是最好的选择。

其次使用开源软件,会使得招聘相对容易,市场上火的开源软件会有大批的从业者,参与各种论坛和社区,比较容易挖到人。

最后,开源软件的使用使得新人来了之后没有预热时间,来了就上手,保证开发速度。

那如何快速上手一款开源软件呢?我总结了如下九个步骤:

  • 手动安装起来,一定要手动。
  • 使用一下,推荐 XXX in Action 系列。
  • 读文档,读所有的官方文档,记不住,看不懂也要读下来。
  • 了解核心的原理和算法,推荐 XXX the definitive guide 系列。
  • 看一本源码分析的书,会让你的源码阅读之旅事半功倍。
  • 开始阅读核心逻辑源代码。
  • 编译并 Debug 源代码。
  • 开发一个插件,或者对组件做少量的修改。
  • 大量的运维实践经验和面向真实场景的定制开发。
  • 所以做一个云架构师,一定不能脱离代码,反而要不断的拥抱开源软件。

了解 Linux 基础知识

作为一个云架构师,首要的一点,就是要熟悉 Linux 的基础知识,基本原理了。

说到操作系统,一般有三个维度:

  • 桌面操作系统
  • 移动操作系统
  • 服务器操作系统

Stack Overflow Developer Survey 2018 有这样一个统计,对于开发人员来说,桌面操作系统的排名是 Windows,MacOS,Linux,所以大部分人平时的办公系统都是 Windows。

当然因为办公的原因,平时使用 Windows 的比较多,所以在学校里,很多同学接触到的操作系统基本上都是 Windows,但是一旦从事计算机行业,就一定要跨过 Linux 这道坎。

根据今年 W3Techs 的统计,对于服务器端,Unix-Like OS 占到的比例为近 70%。所谓 Unix-Like OS 包括下图的 Linux,BSD 等一系列。

从这个统计可以看出,随着云计算的发展,软件 SaaS 化,服务化,甚至微服务化,大部分的计算都是在服务端做的,因而要成为云架构师,就必须懂 Linux。

随着移动互联网的发展,客户端基本上以 Android 和 iOS 为主,下图是 Gartner 的统计。

Android 是基于 Linux 内核的。因而客户端也进入了 Linux 阵营,很多智能终端,智能设备等开发职位,都需要懂 Linux 的人员。

学习 Linux 主要包含两部分,一个是怎么用,一个是怎么编程,背后原理是什么。

对于怎么用,上手的话,推荐《鸟哥的 Linux 私房菜》,按着这个手册,就能够学会基本的 Linux 的使用,如果再深入一点,推荐《Linux 系统管理技术手册》,砖头厚的一本书,是 Linux 运维手边必备。

对于怎么编程,上手的话,推荐《Unix 环境高级编程》,有代码,有介绍,有原理,如果对内核的原理感兴趣,推荐《深入理解 Linux 内核》。

Linux 的架构如下图:

我们知道,一台物理机上有很多的硬件,最重要的是 CPU,内存,硬盘,网络,但是一个物理机上要跑很多的程序,这些资源应该给谁用呢?当然是大家轮着用,谁也别独占,谁也别饿死。

为了完成这件事情,操作系统的内核就起到了大管家的作用,将硬件资源分配给不同的用户程序使用,并且在适当的时间将资源拿回来,再分配给其他的用户进程,这个过程称为调度。

操作系统的功能之一:系统调用

当用户程序想请求资源的时候,需要调用操作系统的系统调用接口,这是内核和用户态程序的分界线。

就像你要打车,要通过打车软件的界面,下发打车指令一样,这样打车软件才会给你调度一辆车。

操作系统的功能之二:进程管理

当一个用户进程运行的时候,内核为它分配的资源,总要有一个数据结构保存,哪些资源分配给了这个进程。分配给这个进程的资源往往包括打开的文件,内存空间等。

操作系统的功能之三:内存管理

每个进程有独立的内存空间,内存空间是进程用来存放数据的,就像一间一间的仓库。

为了进程使用方便,每个进程内存空间,在进程的角度来看都是独立的,也即都是从 0 号仓库,1 号仓库,一直到 N 号仓库,都是独享的。

但是从操作系统内核的角度来看,当然不可能独享,而是大家共享,M 号仓库只有一个,你用他就不能用,这就需要一个仓库调度系统,将用户进程的仓库号和实际使用的仓库号对应起来。

例如进程 1 的 10 号仓库,对应到真实的仓库是 110 号,进程 2 的 20 号仓库,对应到真实的仓库是 120 号。

操作系统功能之四:文件系统

对于 Linux 来讲,很多东西都是文件,例如进程号会对应一个文件,建立一个网络连接也对应一个文件。文件系统多种多样,为了能够统一适配,有一个虚拟文件系统的中间层 VFS。

操作系统功能之五:设备管理

设备分两种,一种是块设备,一种是字符设备,例如硬盘就是块设备,可以格式化为文件系统,再如鼠标和键盘的输入输出是字符设备。

操作系统功能之六:网络管理

对于 Linux 来讲,网络也是基于设备和文件系统的,但是由于网络有自己的协议栈,要遵循 TCP/IP 协议栈标准。

了解数据中心和网络基础知识

云平台当然会部署在数据中心里面,由于数据中心里面的硬件设备也是非常专业的,因而很多地方机房部门和云计算部门是两个部门。

但是作为一个云架构师,需要和机房部门进行沟通,因而需要一定的数据中心知识,在数据中心里面,最难搞定的是网络,因而这里面网络知识是重中之重。

下面这个图是一个典型的数据中心图:

最外层是 Internet Edge,也叫 Edge Router,也叫 Border Router,它提供数据中心与 Internet 的连接。

第一层 Core Network,包含很多的 Core Switches:

  • Available Zone 同 Edge Router 之间通信。
  • Available Zone 之间的通信提供。
  • 提供高可用性连接 HA。
  • 提供 Intrusion Prevention Services。
  • 提供 Distributed Denial of Service Attack Analysis and Mitigation。
  • 提供 Tier 1 Load Balancer

第二层也即每个 AZ 的最上层,我们称为 Aggregation Layer。

第三层是 Access Layer,就是一个个机架的服务器,用接入交换机连接在一起。

这是一个典型的三层网络结构,也即接入层、汇聚层、核心层三层。除了数据中心以外,哪怕是做应用架构,对于网络的了解也是必须的。

云架构说到底是分布式架构,既然是分布式,就是去中心化的,因而就需要系统之间通过网络进行互通,因而网络是作为大规模系统架构绕不过去的一个坎。

对于网络的基本原理,推荐书籍《计算机网络-严伟与潘爱民译》,《计算机网络:自顶向下方法》。

对于 TCP/IP 协议栈的了解,推荐书籍《TCP/IP 详解》,《The TCP/IP Guide》。

对于网络程序设计,推荐书籍《Unix 网络编程》,如果你想了解网络协议栈的实现,推荐书籍《深入理解 Linux 网络内幕》 。

基于 KVM 了解计算虚拟化

当物理机搭建完毕之后,接下来就是基于物理机上面搭建虚拟机了。

没有了解虚拟机的同学,可以在自己的笔记本电脑上用 VirtualBox 或者 Vmware 创建虚拟机,你会发现,很容易就能在物理机的操作系统之内再安装多个操作系统。

通过这种方式,你可以很方便的在 Windows 办公系统之内安装一个 Linux 系统,从而保持 Linux 系统的持续学习。

前面讲 Linux 操作系统的时候,说到操作系统,就是整个系统的管家。应用程序要申请资源,都需要通过操作系统的系统调用接口,向操作系统内核申请将 CPU,内存,网络,硬盘等资源分配给他。

这时候你会发现,虚拟机也是物理机上的一个普通进程,当虚拟机内部的应用程序申请资源的时候,需要向虚拟机的操作系统请求。

然而虚拟机的操作系统自己本身也没有权限操作资源,因而又需要像物理机的操作系统申请资源。

这中间要多一次翻译的工作,完成这件事情的称为虚拟化软件。例如上面说的 VirtualBox 和 Vmware 都是虚拟化软件。

但是多一层翻译,就多一层性能损耗,如果虚拟机里面的每一个操作都要翻译,都不能直接操作硬件,性能就会差很多,简直没办法用,于是就出现了上图中的硬件辅助虚拟化,也即通过硬件的特殊配置。

例如 VT-x 和 VT-d 等,让虚拟机里面的操作系统知道,它不是一个原生的操作系统了,是一个虚拟机的操作系统,不能按照原来的模式操作资源了,而是通过特殊的驱动以硬件辅助的方式抄近道操作物理资源。

刚才说的是桌面虚拟化,也就是在你的笔记本电脑上,在数据中心里面,也可以使用 Vmware 进行虚拟化,但是价格比较贵,如果规模比较大,会采取开源的虚拟化软件 qemu-kvm。

对于 qemu-kvm 来说,和上面的原理是一样的,其中 qemu 的 emu 是 emulator 的意思,也即模拟器,就是翻译的意思。

KVM 是一个可以使用 CPU 的硬件辅助虚拟化的方式,而网络和存储的,需要通过特殊的 virtio 的方式,提供高性能的设备虚拟化功能。

要了解虚拟化的基本原理,推荐书籍《系统虚拟化——原理与实现》,要了解 KVM,推荐两本书籍《KVM Virtualization Cookbook》和《Mastering KVM Virtualization》。

另外 KVM 和 qemu 的官方文档也是必须要看的,还有 Redhat 的官网很多文章非常值得学习。

基于 Openvswitch 了解网络虚拟化

当虚拟机创建出来了,最主要的诉求就是要能上网,它能访问到网上的资源,如果虚拟机里面部署一个网站,也希望别人能够访问到它。

这一方面依赖于 qemu-KVM 的网络虚拟化,将网络包从虚拟机里面传播到虚拟机外面,这需要物理机内核转换一把,形成虚拟机内部的网卡和虚拟机外部的虚拟网卡。

另外一方面就是虚拟机的网络如何能够连接到物理网络里面。物理网络常常称为 underlay network,虚拟网络常常称为 overlay network。

从物理网络到虚拟网络称为网络虚拟化,能非常好的完成这件事情的是一个叫 Openvswitch 的虚拟交换机软件。

Openvswitch 会有一个内核驱动,监听物理网卡,可以将物理网卡上收到的包拿进来。

虚拟机创建出来的外部的虚拟网卡也可以添加到 Openvswitch 上,而 Openvswitch 可以设定各种的网络包处理策略,将网络包在虚拟机和物理机之间进行传递,从而实现了网络虚拟化。

对于 Openvswitch,我主要是通过官方文档进行研究。

基于 OpenStack 了解云平台

当有了虚拟机,并且虚拟机能够上网了之后,接下来就是搭建云平台的时候了。

云是基于计算,网络,存储虚拟化技术的,云和虚拟化的主要区别在于,管理员的管理模式不同,用户的使用模式也不同。

虚拟化平台没有多层次的丰富的租户管理,没有灵活 quota 配额的限制,没有灵活的 QoS 的限制。

多采用虚拟网络和物理网络打平的桥接模式,虚拟机直接使用机房网络,没有虚拟子网 VPC 的概念,虚拟网络的管理和隔离不能和租户隔离完全映射起来。

对于存储也是,公司采购了统一的存储,也不能和租户的隔离完全映射起来。

使用虚拟化平台的特点是,对于这个平台的操作完全由运维部门统一管理,而不能将权限下放给业务部门自己进行操作。

因为一旦允许不同的部门自己操作,大家都用机房网络,在没有统一管控的情况下,很容易网段冲突了。

如果业务部门想申请虚拟机,需要通过工单向运维部门提统一的申请。当然这个运维部门很适应这种方式,因为原来物理机就是这样管理的。

但是公有云,例如 AWS 就没办法这样,租户千千万万,只能他们自己操作。

在私有云里面,随着服务化甚至微服务化的进行,服务数目越来越多,迭代速度越来越快,业务部门需要更加频繁的创建和消耗虚拟机,如果还是由运维部统一审批,统一操作,会使得运维部门压力非常大。

而且还会极大限制了迭代速度,因而要引入租户管理,运维部灵活配置每个租户的配额 quota 和 QoS,在这个配额里面,业务部门随时可以按照自己的需要,创建和删除虚拟机,无需知会运维部门。

每个部门都可以创建自己的虚拟网络 VPC,不同租户的 VPC 之前完全隔离。

所以网段可以冲突,每个业务部门自己规划自己的网络架构,只有少数的机器需要被外网或者机房访问的时候,需要少数的机房 IP。

这个也是和租户映射起来的,可以在分配给业务部门机房网 IP 的个数范围内,自由的使用。这样每个部门自主操作,迭代速度就能够加快了。

云平台中的开源软件的代表是 OpenStack,建议大家研究 OpenStack 的设计机制,是在云里面通用的,了解了 OpenStack,对于公有云,容器云,都能发现相似的概念和机制。

通过我们研究 OpenStack,我们会发现很多非常好的云平台设计模式。

第一:基于 PKI Token 的认证模式

如果我们要实现一个 Restful API,希望有个统一的认证中心的话,Keystone 的三角形工作模式是常用的。

当我们要访问一个资源,通过用户名密码或者 AK/SK 登录之后,如果认证通过,接下来对于资源的访问,不应该总带着用户名密码,而是登录的时候形成一个 Token,然后访问资源的时候带着 Token,服务端通过 Token 去认证中心进行验证即可。

如果每次验证都去认证中心,效率比较差,后来就有了 PKI Token,也即 Token 解密出来是一个有详细租户信息的字符串,这样本地就可以进行认证和鉴权。

 

 

第二:基于 Role Based Access Control 的鉴权模式

对于权限控制,我们学会比较通用的 Role Based Access Control 的权限控制模式, 形成“用户-角色-权限”的授权模型。

在这种模型中,用户与角色之间,角色与权限之间,一般两者是多对多的关系,可以非常灵活的控制权限。

 

第三:基于 Quota 的配额管理

可以通过设置计算,网络,存储的 quota,设置某个租户自己可以自主操作的资源量。

第四:基于预选和优选两阶段的 Scheduler 机制

当需要从一个资源池里面,选择一个节点,使用这个节点上的资源的时候,一个通用的 Scheduler 机制是:

首先进行预选,也即通过 Filter,将不满足条件的过滤掉。

然后进行优选,也即对于过滤后,满足条件的候选人,通过计算权重,选择其中最优的。

第五:基于独立虚拟子网的网络模式

为了每个租户可以独立操作,因而虚拟网络应该是独立于物理网络的,这样不同的租户可以进行独立的网络规划而互不影响,也不影响物理网络,当需要跨租户访问,或者要访问物理网络的时候,需要通过路由器。

第六:基于 Copy On Write 的镜像机制

有时候我们在虚拟机里面做了一些操作以后,希望能够把这个时候的镜像保存下来,好随时恢复到这个时间点,一个最最简单的方法就是完全复制一份,但是由于镜像太大了,这样效率很差。

因而采取 Copy On Write 的机制,当打镜像的时刻,并没有新的存储消耗,而是当写入新的东西的时候,将原来的数据找一个地方复制保存下来,这就是 Copy On Write。

对于 Openstack,有一种镜像 qcow2 就是采取的这样的机制。

这样镜像就像分层一样,一层一层的罗列上去。

第七:基于 namespace 和 cgroup 的隔离和 Qos 机制

在 OpenStack 里面,网络节点的路由器是由 network namespace 来隔离的。

KVM 的占用的 CPU 和内存,使用 Cgroup 来隔离的。

网络的 QoS 使用 TC 来隔离的。

第八:基于 iptables 的安全机制

有时候,我们希望网络中的节点之间不能相互访问,作为最简单的防火墙,iptables 起到了很重要的作用,以后实现 ACL 机制的,都可以考虑使用 iptables。

基于 Mesos 和 Kubernetes 了解容器平台

搭建完毕虚拟化层和云平台层,接下来就是容器层了。Docker 有几个核心技术,一个是镜像,一个是运行时,运行时又分看起来隔离的 namespace 和用起来隔离的 cgroup。

Docker 的镜像也是一种 Copy On Write 的镜像格式,下面的层级是只读的,所有的写入都在最上层。

对于运行时,Docker 使用的 namespace 除了 network namespace 外,还有很多,如下表格所示。

Docker 对于 cgroup 的使用是在运行 Docker 的时候,在路径 /sys/fs/cgroup/cpu/docker/ 下面控制容器运行使用的资源。

可见容器并没有使用更新的技术,而是一种新型的交付方式,也即应用的交付应该是一容器镜像的方式交付,容器一旦启动起来,就不应该进入容器做各种修改,这就是不可改变基础设施。

由于容器的镜像不包含操作系统内核,因而小的多,可以进行跨环境的迁移和弹性伸缩。

有了容器之后,接下来就是容器平台的选型,其实 Swarm、Mesos、Kubernetes 各有优势,也可以在不同的阶段,选择使用不同的容器平台。

基于 Mesos 的 DCOS 更像是一个数据中心管理平台,而非仅仅容器管理平台,它可以兼容 Kubernetes 的编排,同时也能跑各种大数据应用。

在容器领域,基于 Kubernetes 的容器编排已经成为事实标准。

当我们深入分析 Kubernetes 管理容器模式的时候,我们也能看到熟悉的面孔。

在 Kubernetes 里面,租户之间靠 namespace 进行隔离,这个不是 Docker 的 namespace,而是 Kubernetes 的概念。

API Server 的鉴权,也是基于 Role Based Access Control 模式的。Kubernetes 对于 namespace,也有 Quota 配置,使用 ResourceQuota。

当 Kubernetes 想选择一个节点运行 pod 的时候,选择的过程也是通过预选和优选两个阶段:

预选(Filtering)

  • PodFitsResources 满足资源。
  • PodSelectorMatches 符合标签。
  • PodFitsHost 符合节点名称。

优选(Weighting)

  • LeastRequestedPriority 资源消耗最小。
  • BalancedResourceAllocation 资源使用最均衡。

Kubernetes 规定了以下的网络模型定义:

  • 所有的容器都可以在不使用 NAT 的情况下同别的容器通信。
  • 所有的节点都可以在不使用 NAT 的情况下同所有的容器通信。
  • 容器的地址和别人看到的地址一样。

也即容器平台应该有自己的私有子网,常用的有 Flannel、Calico、Openvswitch 都是可以的。

既可以使用 Overlay 的方式,如图 Flannel:

也可以使用 BGP 的方式,如图 Calico:

基于 Hadoop 和 Spark 了解大数据平台

对于数据架构的部分,其实经历了三个过程,分别是 Hadoop Map-Reduce 1.0,基于 Yarn 的 Map-Reduce 2.0,还有 Spark。

如下图是 Map-Reduce 1.0 的过程:

Map-Reduce 的过程将一个大任务,split 成为多个 Map Task,分散到多台机器并行处理,将处理的结果保存到本地,第二个阶段,Reduce Task 将中间结果拷贝过来,将结果集中处理,取得最终结果。

在 Map-Reduce 1.0 的时候,跑任务的方式只有这一种,为了应对复杂的场景,将任务的调度和资源的调度分成两层。

其中资源的调用由 Yarn 进行,Yarn 不管是 Map 还是 Reduce,只要向它请求,它就找到空闲的资源分配给它。

每个任务启动的时候,专门启动一个 Application Master,管理任务的调度,它是知道 Map 和 Reduce 的。这就是 Map-Reduce 2.0,如下图:

这里 Yarn 相当于外包公司的老板,所有的员工都是 Worker,都是他的资源,外包公司的老板是不清楚接的每一个项目的。

Application Master 相当于接的每个项目的项目经理,他是知道项目的具体情况的,他在执行项目的时候,如果需要员工干活,需要向外包公司老板申请。

Yarn 是个通用的调度平台,能够跑 Map-Reduce 2,就能跑 Spark。

Spark 也是创建 Spark 自己的 Application Master,用于调度任务。

Spark 之所以比较快,是因为前期规划做的好,不是像 Map-Reduce 一样,每一次分配任务和聚合任务都要写一次硬盘,而是将任务分成多个阶段,将所有在一个 Map 都做了的合成一个阶段,这样中间不用落盘,但是到了需要合并的地方,还是需要落盘的。

基于 Lucene 和 ElasticSearch 了解搜索引擎

当大数据将收集好的数据处理完毕之后,一般会保存在两个地方,一个是正向索引,可以用 Hbase,Cassandra 等文档存储,一个是反向索引,方便搜索,就会保存在基于 Lucene 的 ElasticSearch 里面。

基于 Spring Cloud 了解微服务

最后到了应用架构,也即微服务。接下来细说微服务架构设计中不得不知的十大要点。

设计要点一:负载均衡 + API 网关

在实施微服务的过程中,不免要面临服务的聚合与拆分。

当后端服务的拆分相对比较频繁的时候,作为手机 App 来讲,往往需要一个统一的入口,将不同的请求路由到不同的服务,无论后面如何拆分与聚合,对于手机端来讲都是透明的。

有了 API 网关以后,简单的数据聚合可以在网关层完成,这样就不用在手机 App 端完成,从而手机 App 耗电量较小,用户体验较好。

有了统一的 API 网关,还可以进行统一的认证和鉴权,尽管服务之间的相互调用比较复杂,接口也会比较多。

API 网关往往只暴露必须的对外接口,并且对接口进行统一的认证和鉴权,使得内部的服务相互访问的时候,不用再进行认证和鉴权,效率会比较高。

有了统一的 API 网关,可以在这一层设定一定的策略,进行 A/B 测试,蓝绿发布,预发环境导流等等。API 网关往往是无状态的,可以横向扩展,从而不会成为性能瓶颈。

设计要点二:无状态化与独立有状态集群

影响应用迁移和横向扩展的重要因素就是应用的状态。无状态服务,是要把这个状态往外移,将 Session 数据,文件数据,结构化数据保存在后端统一的存储中,从而应用仅仅包含商务逻辑。

状态是不可避免的,例如 ZooKeeper,DB,Cache 等,把这些所有有状态的东西收敛在一个非常集中的集群里面。整个业务就分两部分,一个是无状态的部分,一个是有状态的部分。

无状态的部分能实现两点:

  • 跨机房随意地部署,也即迁移性。
  • 弹性伸缩,很容易地进行扩容。

有状态的部分,如 ZooKeeper,DB,Cache 有自己的高可用机制,要利用到它们自己高可用的机制来实现这个状态的集群。

虽说无状态化,但是当前处理的数据,还是会在内存里面的,当前的进程挂掉数据,肯定也是有一部分丢失的。

为了实现这一点,服务要有重试的机制,接口要有幂等的机制,通过服务发现机制,重新调用一次后端服务的另一个实例就可以了。

设计要点三:数据库的横向扩展

数据库是保存状态,是最重要的也是最容易出现瓶颈的。有了分布式数据库可以使数据库的性能随着节点增加线性地增加。

分布式数据库最最下面是 RDS,是主备的,通过 MySQL 的内核开发能力,我们能够实现主备切换数据零丢失。

所以数据落在这个 RDS 里面,是非常放心的,哪怕是挂了一个节点,切换完了以后,你的数据也是不会丢的。

再往上就是横向怎么承载大的吞吐量的问题,上面有一个负载均衡 NLB,用 LVS,HAProxy,Keepalived,下面接了一层 Query Server。

Query Server 是可以根据监控数据进行横向扩展的,如果出现了故障,可以随时进行替换的修复,对于业务层是没有任何感知的。

另外一个就是双机房的部署,DDB 开发了一个数据运河 NDC 的组件,可以使得不同的 DDB 之间在不同的机房里面进行同步。

这时候不但在一个数据中心里面是分布式的,在多个数据中心里面也会有一个类似双活的一个备份,高可用性有非常好的保证。

设计要点四:缓存

在高并发场景下缓存是非常重要的。要有层次的缓存,使得数据尽量靠近用户。数据越靠近用户能承载的并发量也越大,响应时间越短。

在手机客户端 App 上就应该有一层缓存,不是所有的数据都每时每刻从后端拿,而是只拿重要的,关键的,时常变化的数据。

尤其对于静态数据,可以过一段时间去取一次,而且也没必要到数据中心去取,可以通过 CDN,将数据缓存在距离客户端最近的节点上,进行就近下载。

有时候 CDN 里面没有,还是要回到数据中心去下载,称为回源,在数据中心的最外层,我们称为接入层,可以设置一层缓存,将大部分的请求拦截,从而不会对后台的数据库造成压力。

如果是动态数据,还是需要访问应用,通过应用中的商务逻辑生成,或者去数据库读取,为了减轻数据库的压力,应用可以使用本地的缓存,也可以使用分布式缓存。

如 Memcached 或者 Redis,使得大部分请求读取缓存即可,不必访问数据库。

当然动态数据还可以做一定的静态化,也即降级成静态数据,从而减少后端的压力。

设计要点五:服务拆分与服务发现

当系统扛不住,应用变化快的时候,往往要考虑将比较大的服务拆分为一系列小的服务。

这样第一个好处就是开发比较独立,当非常多的人在维护同一个代码仓库的时候,往往对代码的修改就会相互影响。

常常会出现我没改什么测试就不通过了,而且代码提交的时候,经常会出现冲突,需要进行代码合并,大大降低了开发的效率。

另一个好处就是上线独立,物流模块对接了一家新的快递公司,需要连同下单一起上线,这是非常不合理的行为。

我没改还要我重启,我没改还让我发布,我没改还要我开会,都是应该拆分的时机。

再就是高并发时段的扩容,往往只有最关键的下单和支付流程是核心,只要将关键的交易链路进行扩容即可,如果这时候附带很多其他的服务,扩容既是不经济的,也是很有风险的。

另外的容灾和降级,在大促的时候,可能需要牺牲一部分的边角功能,但是如果所有的代码耦合在一起,很难将边角的部分功能进行降级。

当然拆分完毕以后,应用之间的关系就更加复杂了,因而需要服务发现的机制,来管理应用相互的关系,实现自动的修复,自动的关联,自动的负载均衡,自动的容错切换。

设计要点六:服务编排与弹性伸缩

 

当服务拆分了,进程就会非常的多,因而需要服务编排来管理服务之间的依赖关系,以及将服务的部署代码化,也就是我们常说的基础设施即代码。

这样对于服务的发布,更新,回滚,扩容,缩容,都可以通过修改编排文件来实现,从而增加了可追溯性,易管理性,和自动化的能力。

既然编排文件也可以用代码仓库进行管理,就可以实现一百个服务中,更新其中五个服务,只要修改编排文件中的五个服务的配置就可以。

当编排文件提交的时候,代码仓库自动触发自动部署升级脚本,从而更新线上的环境。

当发现新的环境有问题时,当然希望将这五个服务原子性地回滚,如果没有编排文件,需要人工记录这次升级了哪五个服务。

有了编排文件,只要在代码仓库里面 Revert,就回滚到上一个版本了。所有的操作在代码仓库里都是可以看到的。

设计要点七:统一配置中心

 

服务拆分以后,服务的数量非常多,如果所有的配置都以配置文件的方式放在应用本地的话,非常难以管理。

可以想象当有几百上千个进程中有一个配置出现了问题,是很难将它找出来的,因而需要有统一的配置中心,来管理所有的配置,进行统一的配置下发。

在微服务中,配置往往分为以下几类:

一类是几乎不变的配置,这种配置可以直接打在容器镜像里面。

第二类是启动时就会确定的配置,这种配置往往通过环境变量,在容器启动的时候传进去。

第三类就是统一的配置,需要通过配置中心进行下发。例如在大促的情况下,有些功能需要降级,哪些功能可以降级,哪些功能不能降级,都可以在配置文件中统一配置。

设计要点八:统一日志中心

同样是进程数目非常多的时候,很难对成千上百个容器,一个一个登录进去查看日志,所以需要统一的日志中心来收集日志。

为了使收集到的日志容易分析,对于日志的规范,需要有一定的要求,当所有的服务都遵守统一的日志规范的时候,在日志中心就可以对一个交易流程进行统一的追溯。

例如在最后的日志搜索引擎中,搜索交易号,就能够看到在哪个过程出现了错误或者异常。

设计要点九:熔断,限流,降级

服务要有熔断,限流,降级的能力,当一个服务调用另一个服务,出现超时的时候,应及时返回,而非阻塞在那个地方,从而影响其他用户的交易,可以返回默认的托底数据。

当一个服务发现被调用的服务,因为过于繁忙,线程池满,连接池满,或者总是出错,则应该及时熔断,防止因为下一个服务的错误或繁忙,导致本服务的不正常,从而逐渐往前传导,导致整个应用的雪崩。

当发现整个系统的确负载过高的时候,可以选择降级某些功能或某些调用,保证最重要的交易流程的通过,以及最重要的资源全部用于保证最核心的流程。

还有一种手段就是限流,当既设置了熔断策略,又设置了降级策略,通过全链路的压力测试,应该能够知道整个系统的支撑能力。

因而就需要制定限流策略,保证系统在测试过的支撑能力范围内进行服务,超出支撑能力范围的,可拒绝服务。

当你下单的时候,系统弹出对话框说 “系统忙,请重试”,并不代表系统挂了,而是说明系统是正常工作的,只不过限流策略起到了作用。

设计要点十:全方位的监控

当系统非常复杂的时候,要有统一的监控,主要有两个方面,一个是是否健康,一个是性能瓶颈在哪里。

当系统出现异常的时候,监控系统可以配合告警系统,及时地发现,通知,干预,从而保障系统的顺利运行。

当压力测试的时候,往往会遭遇瓶颈,也需要有全方位的监控来找出瓶颈点,同时能够保留现场,从而可以追溯和分析,进行全方位的优化。

版权声明:本文为davidwang456原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/davidwang456/articles/9927397.html