什么是云

2006年8月9日，Google首席執(zhí)行官Eric?Schmidt在搜索引擎大會(huì)（SES?San?Jose?2006）上首次提出云計(jì)算概念。云計(jì)算是網(wǎng)格計(jì)算，分布式計(jì)算，并行計(jì)算、效用技術(shù)、網(wǎng)絡(luò)存儲(chǔ)、虛擬化和負(fù)載均衡等傳統(tǒng)計(jì)算機(jī)和網(wǎng)絡(luò)技術(shù)發(fā)展融合的產(chǎn)物。其目的是通過(guò)基于網(wǎng)絡(luò)的計(jì)算方式，將共享的軟件/硬件

資源和信息進(jìn)行組織整合，按需提供給計(jì)算機(jī)和其他系統(tǒng)使用。

什么是架構(gòu)

從三方面去理解架構(gòu)。

第一是IT架構(gòu)，其實(shí)就是計(jì)算，網(wǎng)絡(luò)，存儲(chǔ)。這是云架構(gòu)師的基本功，也是最傳統(tǒng)的云架構(gòu)師應(yīng)該首先掌握的部分，良好設(shè)計(jì)的IT架構(gòu)，可以提高系統(tǒng)可靠性，降低減輕運(yùn)維負(fù)擔(dān)。數(shù)據(jù)中心，虛擬化，云平臺(tái)，容器平臺(tái)都屬于IT架構(gòu)的范疇。

第二是應(yīng)用架構(gòu)，隨著應(yīng)用從傳統(tǒng)應(yīng)用向互聯(lián)網(wǎng)應(yīng)用轉(zhuǎn)型，僅僅提高資源層面的彈性還不夠，常常會(huì)出現(xiàn)創(chuàng)建了大批機(jī)器，仍然撐不住高并發(fā)流量。因而基于微服務(wù)的互聯(lián)網(wǎng)架構(gòu)，越來(lái)越成為云架構(gòu)師所必需的技能。良好設(shè)計(jì)的應(yīng)用架構(gòu)，可以實(shí)現(xiàn)快速迭代和高并發(fā)。數(shù)據(jù)庫(kù)，緩存，消息隊(duì)列等PaaS，以及基于SpringCloud和Dubbo的微服務(wù)框架，都屬于應(yīng)用架構(gòu)的范疇。

第三是數(shù)據(jù)架構(gòu)，數(shù)據(jù)成為人工智能時(shí)代的核心資產(chǎn)，在做互聯(lián)網(wǎng)化轉(zhuǎn)型的同時(shí)，往往進(jìn)行的也是數(shù)字化轉(zhuǎn)型，并有戰(zhàn)略的進(jìn)行數(shù)據(jù)收集，這就需要云架構(gòu)師同時(shí)又大數(shù)據(jù)思維。有意識(shí)的建設(shè)統(tǒng)一的數(shù)據(jù)平臺(tái)，并給予數(shù)據(jù)進(jìn)行數(shù)字化運(yùn)營(yíng)。搜索引擎，Hadoop，Spark，HBase，人工智能都屬于數(shù)據(jù)架構(gòu)的范疇。

云架構(gòu)技術(shù)棧

從系統(tǒng)的角度出發(fā)，架構(gòu)分六個(gè)層次。

1、基礎(chǔ)設(shè)施層：在數(shù)據(jù)中心里面，會(huì)有大量的機(jī)架，大量的服務(wù)器，并通過(guò)交換機(jī)和路由器將服務(wù)器連接起來(lái)，有的應(yīng)用例如Oracle是需要部署在物理機(jī)上的。為了管理的方便，在物理機(jī)之上會(huì)部署虛擬化，例如Vmware，可以將對(duì)于物理機(jī)復(fù)雜的運(yùn)維簡(jiǎn)化為虛擬機(jī)靈活的運(yùn)維。虛擬化采取的運(yùn)維方式多是由運(yùn)維部門(mén)統(tǒng)一管理，當(dāng)一個(gè)公司里面部門(mén)非常多的時(shí)候，往往要引入良好的租戶(hù)管理，基于Quota和QoS的資源控制，基于VPC的網(wǎng)絡(luò)規(guī)劃等，實(shí)現(xiàn)從運(yùn)維集中管理到租戶(hù)自助使用模式的轉(zhuǎn)換，托生于公有云的OpenStack在這方面做的是比較好的。隨著應(yīng)用架構(gòu)越來(lái)越重要，對(duì)于標(biāo)準(zhǔn)化交付和彈性伸縮的需求越來(lái)越大，容器最為軟件交付的集裝箱，可以實(shí)現(xiàn)基于鏡像的跨環(huán)境遷移，Kubernetes是容器管理平臺(tái)的事實(shí)標(biāo)準(zhǔn)。

2、數(shù)據(jù)層：也即一個(gè)應(yīng)用的中軍大營(yíng)，如果是傳統(tǒng)應(yīng)用，可能會(huì)使用Oracle，并使用大量的存儲(chǔ)過(guò)程，有大量的表聯(lián)合查詢(xún)，成本也往往比較高。但是對(duì)于高并發(fā)的互聯(lián)網(wǎng)應(yīng)用，需要進(jìn)行微服務(wù)的拆分，數(shù)據(jù)庫(kù)實(shí)例會(huì)比較多，使用開(kāi)源的Mysql是常見(jiàn)的選擇，大量的存儲(chǔ)過(guò)程和聯(lián)合查詢(xún)往往會(huì)使得微服務(wù)無(wú)法拆分，性能會(huì)比較差，因而需要放到應(yīng)用層去做復(fù)雜的業(yè)務(wù)邏輯，數(shù)據(jù)庫(kù)表和索引的設(shè)計(jì)非常重要。當(dāng)并發(fā)量比較大的時(shí)候，需要實(shí)現(xiàn)橫向擴(kuò)展，就需要基于分布式數(shù)據(jù)庫(kù)，也是需要基于單庫(kù)良好的表和索引設(shè)計(jì)。對(duì)于結(jié)構(gòu)比較靈活的數(shù)據(jù)，可以使用MongoDB數(shù)據(jù)庫(kù)，橫向擴(kuò)展能力比較好。對(duì)于大量的聯(lián)合查詢(xún)需求，可以使用ElasticSearch之類(lèi)的搜索引擎來(lái)做，速度快，更加靈活。

3、中間件層：因?yàn)閿?shù)據(jù)庫(kù)層往往需要保證數(shù)據(jù)的不丟失以及一些事務(wù)，因而并發(fā)性能不可能非常大，所以我們經(jīng)常說(shuō)，數(shù)據(jù)庫(kù)是中軍大營(yíng)，不能所有的請(qǐng)求都到這里來(lái)，因而需要一層緩存層，用來(lái)攔截大部分的熱點(diǎn)請(qǐng)求。Memcached適合做簡(jiǎn)單的key-value存儲(chǔ)，內(nèi)存使用率比較高，而且由于是多核處理，對(duì)于比較大的數(shù)據(jù)，性能較好。但是缺點(diǎn)也比較明顯，Memcached嚴(yán)格來(lái)講沒(méi)有集群機(jī)制，橫向擴(kuò)展完全靠客戶(hù)端來(lái)實(shí)現(xiàn)。另外Memcached無(wú)法持久化，一旦掛了數(shù)據(jù)就都丟失了，如果想實(shí)現(xiàn)高可用，也是需要客戶(hù)端進(jìn)行雙寫(xiě)才可以。Redis的數(shù)據(jù)結(jié)構(gòu)比較豐富，提供持久化的功能，提供成熟的主備同步，故障切換的功能，從而保證了高可用性。另外微服務(wù)拆分以后，有時(shí)候處理一個(gè)訂單要經(jīng)過(guò)非常多的服務(wù)，處理過(guò)程會(huì)比較慢，這個(gè)時(shí)候需要使用消息隊(duì)列，讓服務(wù)之間的調(diào)用變成對(duì)于消息的訂閱，實(shí)現(xiàn)異步處理。RabbitMQ和Kafka是常用的消息隊(duì)列，當(dāng)事件比較重要的時(shí)候，會(huì)結(jié)合數(shù)據(jù)庫(kù)實(shí)現(xiàn)可靠消息隊(duì)列。

4、基礎(chǔ)服務(wù)層：有的時(shí)候成為中臺(tái)層，將通用的能力抽象為服務(wù)對(duì)外提供原子化接口。這樣上層可以根據(jù)業(yè)務(wù)需求，通過(guò)靈活的組合這些原子化接口，靈活的應(yīng)對(duì)業(yè)務(wù)需求的變化，實(shí)現(xiàn)能力的復(fù)用，以及數(shù)據(jù)的統(tǒng)一管理，例如用戶(hù)數(shù)據(jù)，支付數(shù)據(jù)，不會(huì)分散到各個(gè)應(yīng)用中。另外基礎(chǔ)服務(wù)層稱(chēng)為應(yīng)用和數(shù)據(jù)庫(kù)和緩存的一個(gè)分界線(xiàn)，不應(yīng)該所有的應(yīng)用都直接連數(shù)據(jù)庫(kù)，一旦出現(xiàn)分庫(kù)分表，數(shù)據(jù)庫(kù)遷移，緩存選型改變等，影響面會(huì)非常大，幾乎無(wú)法執(zhí)行。如果將這些底層的變更攔截在基礎(chǔ)服務(wù)層，上層僅僅使用基礎(chǔ)服務(wù)層的接口，這樣底層的變化會(huì)對(duì)上層透明，可以逐步演進(jìn)。

5、第五個(gè)層次是業(yè)務(wù)服務(wù)層，或者組合服務(wù)層，大部分的業(yè)務(wù)邏輯都是在這個(gè)層面實(shí)現(xiàn)，業(yè)務(wù)邏輯比較面向用戶(hù)，因而會(huì)經(jīng)常改變，所以需要組合基礎(chǔ)服務(wù)的接口進(jìn)行實(shí)現(xiàn)。在這一層，會(huì)經(jīng)常進(jìn)行服務(wù)的拆分，實(shí)現(xiàn)開(kāi)發(fā)獨(dú)立，上線(xiàn)獨(dú)立，擴(kuò)容獨(dú)立，容災(zāi)降級(jí)獨(dú)立。微服務(wù)的拆分不應(yīng)該是一個(gè)運(yùn)動(dòng)，而應(yīng)該是一個(gè)遇到耦合痛點(diǎn)的時(shí)候，不斷解決，不斷演進(jìn)的一個(gè)過(guò)程。微服務(wù)拆分之后，有時(shí)候需要通過(guò)分布式事務(wù)，保證多個(gè)操作的原子性，也是在組合服務(wù)層來(lái)實(shí)現(xiàn)的。

6、用戶(hù)接口層：也即對(duì)終端客戶(hù)呈現(xiàn)出來(lái)的界面和APP，但是卻不僅僅是界面這么簡(jiǎn)單。這一層有時(shí)候稱(chēng)為接入層。在這一層，動(dòng)態(tài)資源和靜態(tài)資源應(yīng)該分離，靜態(tài)資源應(yīng)該在接入層做緩存，使用CDN進(jìn)行緩存。也應(yīng)該UI和API分離，界面應(yīng)該通過(guò)組合API進(jìn)行數(shù)據(jù)拼裝。API會(huì)通過(guò)統(tǒng)一的API網(wǎng)關(guān)進(jìn)行統(tǒng)一的管理和治理，一方面后端組合服務(wù)層的拆分對(duì)APP是透明的，一方面當(dāng)并發(fā)量比較大的時(shí)候，可以在這一層實(shí)現(xiàn)限流和降級(jí)。

為了支撐這六個(gè)層次，在左側(cè)是一些公共能力。

持續(xù)集成和持續(xù)發(fā)布是保證微服務(wù)拆分過(guò)程中的快速迭代，以及變更后保證功能不變的，不引入新的Bug。

服務(wù)發(fā)現(xiàn)和服務(wù)治理是微服務(wù)之間互相的調(diào)用，以及調(diào)用過(guò)程中出現(xiàn)異常情況下的熔斷，限流，降級(jí)策略。

大數(shù)據(jù)和人工智能是通過(guò)收集各個(gè)層面的數(shù)據(jù)，例如用戶(hù)訪(fǎng)問(wèn)數(shù)據(jù)，用戶(hù)下單數(shù)據(jù)，客服詢(xún)問(wèn)數(shù)據(jù)等，結(jié)合統(tǒng)一的中臺(tái)，對(duì)數(shù)據(jù)進(jìn)行分析，實(shí)現(xiàn)智能推薦。

監(jiān)控是基礎(chǔ)設(shè)施的監(jiān)控和應(yīng)用的監(jiān)控，發(fā)現(xiàn)資源層面的問(wèn)題以及應(yīng)用調(diào)用的問(wèn)題。