一、架构的三个维度和六个层面
1.1、三大架构
在互联网时代,要做好一个合格的云架构师,需要熟悉三大架构。
第一个是IT架构,其实就是计算,网络,存储。这是云架构师的基本功,也是最传统的云架构师应该首先掌握的部分,良好设计的IT架构,可以降低CAPEX和OPEX,减轻运维的负担。数据中心,虚拟化,云平台,容器平台都属于IT架构的范畴。
第二个是应用架构,随着应用从传统应用向互联网应用转型,仅仅搞定资源层面的弹性还不够,常常会出现创建了大批机器,仍然撑不住高并发流量。因而基于微服务的互联网架构,越来越成为云架构师所必需的技能。良好设计的应用架构,可以实现快速迭代和高并发。数据库,缓存,消息队列等PaaS,以及基于SpringCloud和Dubbo的微服务框架,都属于应用架构的范畴。
第三个是数据架构,数据成为人工智能时代的核心资产,在做互联网化转型的同时,往往进行的也是数字化转型,并有战略的进行数据收集,这就需要云架构师同时又大数据思维。有意识的建设统一的数据平台,并给予数据进行数字化运营。搜索引擎,Hadoop,Spark,人工智能都属于数据架构的范畴。
1.2、六个层面
上面的三个维度是从人的角度出发的,如果从系统的角度出发,架构分六个层次。
第一个层次是基础设施层,在数据中心里面,会有大量的机架,大量的服务器,并通过交换机和路由器将服务器连接起来,有的应用例如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,代码呈上去,就能够表现出实力来了,而且面试官也不需要根据短短的半个小时了解一个人,可以做很多背景调查。
另外由于掌握的技术的通用的,你到下一家公司,马上就能够上手,几乎不需要预热时间,对于双方都有好处。
第五:通过开源软件,我们作为招聘方,比较容易招到相应人员。
如果在创业公司待过的朋友会了解到创业公司招人很难,人员流失很快,而且创业公司往往对于开发进度要求很快,因为大家都在抢时间。因而开源软件对于招聘方来讲,也是好消息。首先创业公司没办法像大公司一样,弄这么多的技术大牛,自己完全落地一套自己的体系,使用开源软件快速搭建一套平台先上线是最好的选择。其次使用开源软件,会使得招聘相对容易,市场上火的开源软件会有大批的从业者,参与各种论坛和社区,比较容易挖到人。最后,开源软件的使用使得新人来了之后没有预热时间,来了就上手,保证开发速度。
转载“刘超的云计算”个人博客,原文链接
欢迎加入“阿里云-数据智能产品交流②群”,DataV、智能语音、图像搜索、OCR等AI产品开放体验!
一:钉钉搜索群号即可入群:23362839
二:扫描下方二维码进群: