作者 范濟安 2016.3.18
云世界里的技術日新月異，新名詞一個接著一個讓人應接不暇，從虛擬化開始，VMware、HyperV、KVM，到云管理平臺VSphere、SystemCenter、OpenStack，再到容器領域的Docker、Kubernetes、Mesos、Swarm，資源管理調度的Yarn、Mesos和今天的微服務Micro Service。這些東東到底是干嘛的？能解決什么問題？它們之間有木有關聯(lián)性？作為多年來運營商IT的一名架構師，筆者試著從自己的角度解讀下云技術的演進與實踐。目的不是論證各項技術，而是想把一些碎片化的知識串接起來，讓大家知道來龍去脈，在有必要的時候做出選擇或去深度研究。當然，文中的觀點只代表作者本人，對與不對供大家參考、指正。
1. 虛擬化與X86
最早有硬件服務器（Server）和軟件應用（Application），兩者之間夾了個操作系統(tǒng)（OS），讓應用程序可以通過它來使用CPU、內存和存儲等。從定位來看叫它系統(tǒng)軟件更加貼切，以區(qū)別于應用軟件。
慢慢硬件和OS就綁在一起了，IBM的Aix，HP的HP-UX，Sun的Solaris；微軟是個例外，可在不同的PC服務器上跑Windows。這種局面鬧得應用也不得不選擇自己的營地，一旦落定后要想再遷移可得費老鼻子勁了，用戶要花錢花力冒風險，廠家賺的盆滿缽溢的。
后來基于統(tǒng)一X86架構的PC服務器越做越好，價格便宜而且有多家產品可選擇，再加上出了個開源的OS，Linux，在上面開發(fā)應用讓您隨時可以更換底層的機器，這一局面大大降低了硬件成本。呼啦一下新應用都在X86上開發(fā)了，有些企業(yè)甚至下了行政命令不許再買小機了。幾家硬件巨頭也只好隨風跟進，但時間一長，利潤空間越擠越小，Sun出局了（賣給Oracle了），IBM把X86產品線轉給聯(lián)想了，只有HP還在那兒苦苦地撐著，X86產品線在中國也和紫光合并了。
不過X86在體量和性能上都不如Unix小機，那它怎么能承受的住原來小機上的那些負載呢？工程師們總是有法子的，單機負載不是太大嗎？我干脆弄個業(yè)務組網(wǎng)，把應用在每臺X86上都裝一份，然后在前端放個LB（負載均衡器），把原來一臺機器上的負載分配到不同的機器上，把負載給均衡了。
您要是專家立馬會問那數(shù)據(jù)怎么辦？應用程序要是太大了太重了怎么辦？為了好保證數(shù)據(jù)一致性，數(shù)據(jù)還得放在同一個庫里，所以在一堆X86后面往往都有臺仍舊是小機的數(shù)據(jù)庫服務器（它也由此成了瓶頸，后面咱們再說怎么解決它，怎么徹底做到去IOE）。應用太大了啟動起來費半天勁怎么辦？還是化整為零的辦法，用了個一般人看了后懵懵的名字叫“應用服務化”或“容器化”，后面我們也會談到。
人們追求效率追求成本的努力永不間斷。在實際生產中X86的使用率并不高，只有10%左右。剛剛在X86上落定的IT人又再琢磨能不能再優(yōu)化些，讓一臺X86當多臺機器使用？虛擬化應運而生。
虛擬化是個啥玩意兒？說白了就是夾在硬件和OS之間一個叫做Hypervisor的東西。它可以把一臺物理機里的CPU、內存、硬盤存儲都抓過來，化整為零重新分配給一個個叫做虛機的“小盒子”。這個概念其實在小機上就存在。每個小盒子具備了一定的硬件資源后，再給它裝個OS它就能像臺真正的機器一樣給應用使用。那個Hypervisor就像個監(jiān)工，哪個小盒子里的資源要是不夠用了，它就動態(tài)地多給一些。這是件多好的事兒呀！再加上一幫專門忽悠人的老美給它取了個云里霧里的名字叫“云計算”，弄了個像供水電一樣的銷售使用模式，這家伙X86+虛擬化一下子就火起來了，風靡了全世界。
2. 云化資源管理
這小盒子一多，多到能有成千上萬個，這時候云管理平臺就出來了，它要管理的主要對象是虛機集群。這時候知道點云計算的您肯定會舉手說OpenStack。
哈哈，您先別急，聽我慢慢道來。剛剛從Unix小機解放出來的用戶試著走進虛擬世界，但很快發(fā)現(xiàn)又有被廠家綁定的危險。虛擬軟件的老大VMware自打推出它的Hypervisor之后，很快又推出了它的管理平臺VSphere；另一大佬微軟比VMware胃口還大，從操作系統(tǒng)Windows、到虛擬軟件HyperV，當然忘不了它的管理平臺SystemCenter。昂貴的軟件使用費逼的用戶又一次轉向開源社區(qū)。一下子虛擬化管理領域熱鬧非凡，混戰(zhàn)到最后剩下的有Eucalyptus（國內叫桉樹）、CloudStack和OpenStack幾家了。
關于他們的優(yōu)劣和成敗原因的分析，已有很多。三者中，Eucalyptus出身最學術，CloudStack出身商業(yè)味最濃，OpenStack介于兩者之間。CloudStack 和Eucalyptus一樣，最開始并不開源，開源后還留了點尾巴，而且自己控制著商業(yè)版本。等發(fā)現(xiàn)這種模式玩不轉了，賣給了Citrix，全部開源后，發(fā)現(xiàn)大家已經(jīng)都在玩OpenStack了。其實OpenStack發(fā)布后直到CloudStack被Citrix再轉賣出去為止，它的易用性和穩(wěn)定性一直和CloudStack有差距。但是架不住OpenStack免費、完全開源、沒有商業(yè)公司控制?？?，人都貪便宜，不想被束縛。
按道理OpenStack只是個虛機管理工具，可是一旦一家獨大之后人們對它的期望也就越來越高，就集萬千寵愛于一身。存儲要管（Cinder、Swift），網(wǎng)絡SDN也要管（Neutron）；虛機要管（Nova、Glance），物理機也要管（Ironic），鬧不好連遺留下來的小機也得一并納入；光是硬件資源還不過癮，中間件、大數(shù)據(jù)（Sahara) 等也都要攏過來。資源種類多了，資源之間的編排(Heat) 也越做越復雜。以前只是管理和集成，現(xiàn)在要深入到更底層的資源了，還要考慮收費計價（Ceilometer）。競爭對手一個個倒下，看似勢頭無敵的時候，也就是最危險的時候。這危險一是來自內部，要做那么些功能開源社區(qū)跟不上趟了，開發(fā)落后于需求，用戶不得不自己找一幫高手來開發(fā)；二是來自外部，來自它所需要管理的對象：虛機。
3. 容器時代的到來
大家還記得虛機是什么吧！虛機就是物理機上的一個個“盒子”，盒子里裝著OS，OS之上是各自的應用。問題就出在這OS上。因為操作系統(tǒng)本身就是一個軟件程序，一個很重的系統(tǒng)軟件因為它包含了形形色色的各類功能。好多功能應用根本就用不上，譬如Web服務器負責處理網(wǎng)絡請求，數(shù)據(jù)庫服務器負責數(shù)據(jù)庫的運行和數(shù)據(jù)庫訪問，等等。這些服務器可能永遠都用不上OS中顯示器、多用戶、多進程等功能。這些場景下的虛機和OS的任務很明確，就是提供最好的存儲、計算、網(wǎng)絡性能。但是OS并沒有隨著虛擬化而重建，大而全的OS功能越多重啟它耗費的時間就越長，也因此拖累了虛機。
這時候兩大改造運動開始了，一個是把OS搬到“盒子”外面讓大家共享，一個是把OS做輕，去掉那些無用的功能。剩下的“盒子”就是當紅子雞 “Docker” 或容器（其實這兩種技術改造路線是相輔相成的）。做輕量級OS比較有名的兩個代表（一看公司的名字就知道干嘛的了）一個叫CoreOS，另一個叫Unikernel。最初CoreOS是一家容器化Linux服務器操作系統(tǒng)創(chuàng)業(yè)公司，同時，該公司使用自家的Linux系統(tǒng)CoreOS為Docker提供服務，并為Docker作出了巨大的貢獻。令人出乎意料的是CoreOS卻與Docker分道揚鑣，另起爐灶，并開發(fā)了類Docker的開源容器Rocket。后來在Linux基金會的調解下，這兩家公司互讓一步，聯(lián)手打造開放容器技術項目（OCP）。OCP是一個非營利性組織，它實際上采用了Docker的技術作為開源容器的軟件技術標準。既然開源了，CoreOS也就放了Docker一馬。做輕OS的另一個廠家Unikernel后來干脆被Docker收購了。自此，Docker成了容器的代名詞。
4. 容器集群管理
Docker被應用接受了，逐漸推廣了，問題也出來了。問題一是和虛機管理平臺一樣，容器一多管理上成了問題啦，需要個容器集群管理系統(tǒng)。問題二是容器是輕量級的，用它來承載大塊頭的應用是不適合的。容器集群管理系統(tǒng)里出了Mesos、Kubernetes和Swarm，這里面谷歌開源出來的Kubernetes被業(yè)界公認為是目前最好的工具，但Mesos對集群資源調度及跨集群任務執(zhí)行有自己的特長而Swarm是Docker公司自己出的Docker管理工具。
Kubernetes是谷歌開源的容器集群管理系統(tǒng)（可以認為是谷歌輸給Docker容器之戰(zhàn)后采用的另一種戰(zhàn)略體現(xiàn)），為封裝應用的容器提供資源調度、部署運行、服務發(fā)現(xiàn)、擴容縮容等一整套功能。Kubernetes不光光是簡單地對Docker的整個生命周期進行管理，它更像個DevOps的PaaS平臺，面向應用開發(fā)者提供開發(fā)、測試和運行Docker的環(huán)境；它對外提供的是RESTful的API端口，每個端口對應的是封裝了應用的Docker或Docker組合（POD），是將POD打了標簽后的服務（Service），或是POD的復制。因為分布式應用出于性能或高可用性的考慮，需要復制多份資源，并且根據(jù)負載情況動態(tài)伸縮。
相比于Kubernetes，Mesos根本提不上對Docker有什么管理功能。Kubernetes所有的如服務注冊、發(fā)現(xiàn)，對外提供RESTful接口等PaaS功能都需要由Mesos之外的一個叫Marathon的組件來完成。Mesos本身更注重對底層資源的調度，把每臺機器上的CPU、內存、存儲聚在一起提供給上層的應用框架使用。每個框架會根據(jù)分配到的資源再細分到各個任務或容器上。如果要拿蘋果比蘋果的話，應該拿Kubernetes和Mesos+Marathon來比較。
5. 集群資源管理與調度
說到這兒有必要把集群資源管理調度搞搞清楚。容器也好，虛機也好，怎樣根據(jù)底層可使用的物理資源的多少來把它們分配給容器或虛機使用？這就是調度或動態(tài)調度。OpenStack 做不好這事，它不能在虛機和資源之間進行調度（VMware的VSphere可以，它有個DRS功能）。Mesos可以，它可以在計算框架和資源之間進行調度；如果計算框架自身具備面向框架內任務的細顆粒度資源調度，而這些任務又是用容器來承載的，那么我們也可以認為Mesos可以在容器與資源之間進行調度（兩級調度）。
這種調度的目的就是要提高設備資源的使用率。譬如當你的大數(shù)據(jù)平臺已不再是唯一的Hadoop集群，其它的數(shù)據(jù)處理框架如Spark、Storm、Kafka等也需要組成集群要你來運行時，你肯定會考慮到資源利用率，運維成本，數(shù)據(jù)共享等因素。企業(yè)一般都希望將所有這些框架部署到一個公共的集群中，讓它們共享集群的資源，并對資源進行統(tǒng)一使用，這樣，便誕生了資源統(tǒng)一管理與調度平臺，其中典型代表就是Mesos和Hadoop生態(tài)體系內的Yarn。
首先，資源統(tǒng)一管理和調度平臺應該提供一個全局跨域的資源管理器。所有接入的框架要先向該資源管理器申請資源，申請成功之后，再由框架自身的調度器決定將分配到的資源交由哪個任務使用；也就是說，整個大的系統(tǒng)是個雙層調度器，第一層是統(tǒng)一管理和調度平臺，另一層是框架自身的調度器。
弄清了這一點也就弄清了Mesos和Yarn的各自定位。Mesos是第一層的資源統(tǒng)一管理與調度，它所覆蓋的框架集群有大數(shù)據(jù)類的（Yarn所能支撐的）和非大數(shù)據(jù)類的（Yarn不能支撐的）。第二層是計算框架自帶的調度器如Yarn（或Kubernetes等），對分配到的資源進行再次分配；也就是說，Mesos將大部分調度任務授權給了計算框架?？偨Y來說，Mesos首先完成粗粒度的資源分配，即：將資源分配給框架，然后由框架進行細粒度的資源分配；而Yarn進行細粒度的分配，即:將資源分配給某個任務。
Yarn和Mesos是否單獨執(zhí)行資源調度還沒有到下定論的時候，雙方也都還在繼續(xù)演進當中，以支持越來越多的框架。好在Mesos不僅僅是做大數(shù)據(jù)分布式計算的框架，所以Mesos往往被稱為數(shù)據(jù)中心操作系統(tǒng)，DCOS，是軟件定義數(shù)據(jù)中心的利器。為了讓兩者能夠更好地整合在一起，發(fā)揮各自的作用，業(yè)界試著用一個叫Myriad的組件來做Y2M或M2Y。不過Myriad的穩(wěn)定性還有待驗證，目前還不能用它來做生產組網(wǎng)。在過渡時期，我們可能不得不考慮由Mesos和Yarn分別組網(wǎng)的情況。
至此，我們可以大致勾勒出來新一代云平臺的邊際圖：
- 底層是各類硬件資源，以X86物理機為主，混搭著虛機、小型機、SAN存儲、SDS存儲、SDN網(wǎng)絡等。
- 這些資源統(tǒng)一由OpenStack（或其它云管理軟件）云平臺來負責管理，管理內容包括自動化部署（OS、虛擬軟件等）、可視化監(jiān)控、IaaS多租戶管理、資源組件目錄、用戶門戶等。
- 在這些資源之上我們可以部署Mesos，用它來匯聚底層資源（CPU、內存、存儲）并根據(jù)需求動態(tài)提供給上層的框架（Kubernetes、Hadoop、Spark、Storm、Kafka、MySQL、Redis等）。
- 這些框架如帶有自身的資源調度器，可將分配到的資源二次細分到各自的任務或容器中。
6. 應用的服務化與微服務化
在前面談到容器是輕量級的，用它來承載大塊頭的應用是不適合的。所以要想通過容器來運行應用必須要對應用進行劃小處理。這要比應用遷移至X86上，數(shù)據(jù)庫能不能在虛機上跑之類的云化改造來的更動筋骨一些。傳統(tǒng)的企業(yè)級應用是單體應用（monolithic application），比如運營商的系統(tǒng)，業(yè)務非常復雜，這種巨型系統(tǒng)，首先要關注的是如何根據(jù)業(yè)務劃分子系統(tǒng)。這種劃分是一種垂直切分，十幾年前開始風行的SOA（Service Oriented Architecture）就是基于這種垂直劃分后的子系統(tǒng)的。在SOA體系里，每個子系統(tǒng)都是獨立的服務（Service），通過服務接口與外部協(xié)作。既然有垂直切分就得有水平切分。傳統(tǒng)的企業(yè)級應用一般是分層結構，如表現(xiàn)層、應用層和數(shù)據(jù)層。如果將垂直切分后的子系統(tǒng)按三層架構來設計，我們會得到更細一步的“服務”。這種橫豎切割的過程也叫做服務化過程。SOA還同時提供了調用服務的接口協(xié)議，XML和WS（Web Service），提供服務之間的通信與整合樞紐：企業(yè)服務總線（ESB），服務編排所需要的業(yè)務規(guī)則流程引擎（BPM）等。
按照 SOA 這種思想和架構原則來改造應用無疑相當于推翻重新開發(fā)一遍，在成本上很難接受而且工作過于復雜。 因此大部分企業(yè)實踐SOA的思路不是劃小應用，而是做不同應用系統(tǒng)間的松耦合集成，讓系統(tǒng)與系統(tǒng)之間通過服務接口（Service API）和企業(yè)服務總線（ESB）進行交互。
應用沒有被劃小，傳統(tǒng)的復雜應用只是通過API將其功能和數(shù)據(jù)進行了開放，但還裝不進輕量級的容器Docker中。實際上應用服務化的目的不是為了使用容器，而是想解決三大問題：一是應用的維護問題，二是應用的開發(fā)問題，三是應用的部署問題。
一個簡單的應用會隨著時間推移逐漸變大。幾年后，一個小而簡單的應用因為改來改去會變成一個龐然大物。一旦你的應用變成一個龐大而又復雜的怪物，維護開發(fā)團隊肯定會很痛苦。敏捷開發(fā)和快速部署舉步維艱，其中最主要的問題就是這個應用太復雜，以至于任何一個程序員都不可能搞懂它。因此，修正bug和添加新功能會變得非常困難，并且很耗時。
我們所要尋求的是加快開發(fā)速度和減少變更代價。怎樣才能加快開發(fā)速度呢？如果我們的開發(fā)不是重造輪子，而是每一次做新產品都可以利用已有的東西，那就會好很多。怎樣才能減少變更代價呢？如果我們能夠理清功能模塊之間的關系，合理分層，每次變更只需要修改其中某個部分，甚至不需要修改代碼，僅僅是改變參數(shù)配置就可以了。 我們先不看軟件行業(yè)，來看一下建筑行業(yè)，他們是怎么蓋樓房的呢？施工之前先設計，把整個樓房分解為不同預制件，比如鋼筋混凝土的樓板、門窗、石膏隔斷墻等，分別在各地生產，最后在現(xiàn)場組裝，所以整個搭建過程非?？臁Ｖ蟮木S修也是那塊壞了，換那塊，不用一動就上下一大串、左右一大片。
除去開發(fā)和維護方面的問題之外，我們還要解決的是應用部署問題。誰沒聽說過由于程序員登錄生產現(xiàn)場誤操作導致整個應用癱瘓，長期無法訪問的現(xiàn)象？這些現(xiàn)象反映了很多企業(yè)的應用部署還是停留在“大鍋飯”階段。所謂的大鍋飯就是包含眾多功能的應用軟件被部署到生產環(huán)境時，基本都是以文件的型式打成一個大軟件包，然后被部署到一個應用服務器上，如WebLogic、Tomcat等（也可以把這些應用服務器看成個大容器）。應用服務器可以提供很多基礎服務比如HTTP服務器，服務目錄或共享庫包等。問題出在同一個應用服務器會接受好幾個不同應用的部署，使得在擴展性、維護性和資源使用上會有很多磕磕絆絆、互相牽連的事情發(fā)生。比如當你改動或新添一個功能后，你需要重新部署你的軟件到應用服務器上，要重新啟動你的應用服務器。裝滿沉重應用的它需要很長時間來啟動；如果可憐的你因為趕活兒沒仔細測試你修改后的軟件，應用服務器啟動不了或啟動一段時間后又趴下了，那你造成的影響不光光是你自己的應用而且連累了應用服務器上所有其它的應用。我敢保證攤上這事兒的你，死的心都有了！
這時候不用我說，你大概也明白了為什么我們要把一個復雜的應用服務化了，也就是說劃小了。
劃小后的應用成了一項項服務（Service），用Docker容器把每個單項服務和它運行所需要的基礎軟件環(huán)境封裝在一起，單獨地部署，直接運行在標準的X86硬件資源之上。如果你劃小后的應用出了問題，影響范圍也只限于它而已。你想增添個新功能，你就加一項容器服務，無需牽一發(fā)而動全身。某項服務使用頻次高了，不夠用了，你就把它的容器多復制幾份，前面加個負載均衡機制就解決了系統(tǒng)的容量問題、高并發(fā)問題。
這時的我已經(jīng)不用再過多跟您解釋什么是“微服務”了。微服務定義：采用一組服務的方式來構建一個應用，服務獨立部署在不同的進程中，不同服務通過一些輕量級交互機制來通信，例如 RPC、HTTP（也就是REST） 等，服務可獨立擴展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以采用不同的編程語言來實現(xiàn)，由獨立的團隊來維護。
微服務與SOA有很多相同之處。兩者都屬于典型的、包含松耦合分布式服務的系統(tǒng)結構。但是兩種架構背后的意圖是不同的：SOA嘗試將應用集成，一般采用中央管理模式（ESB模式）來確保各應用能夠交互運作。微服務嘗試部署新功能，快速有效地擴展開發(fā)團隊。它著重于分散管理、代碼再利用與自動化執(zhí)行。
7. 分布式數(shù)據(jù)庫
應用服務化了，采用了分布式架構被部署在X86服務器上了?？蓴?shù)據(jù)呢？前面說過三層架構的應用展現(xiàn)層和業(yè)務邏輯層都可以做云化改造，唯獨后端的數(shù)據(jù)層還因為數(shù)據(jù)一致性的問題停留在小型機上，成為了瓶頸（訪問量大、擴展性差）。企業(yè)的核心數(shù)據(jù)庫系統(tǒng)一般都采用“小型機＋高端商用數(shù)據(jù)庫＋高端存儲陣列”的集中式架構，也就是我們常說的IOE（IBM的小機、Oracle的數(shù)據(jù)庫、EMC的存儲）。這些設備價格昂貴不說，主要問題還是在于它只允許縱向（Scale-in)而不是橫向擴展（Scale-out)?？v向擴展的意思就是在機器內加配置，加CPU，加內存，加硬盤，加到最后就加不了了；而橫向擴展則能讓您加機器，加節(jié)點；一臺不夠，兩臺，兩臺不夠十臺、百臺、千臺，形成了集群，形成了我們所說的分布式架構。這后種形式的擴展優(yōu)越性不言而喻。那您肯定會說應用都劃小了，怎么不把數(shù)據(jù)庫也分了得了？
和應用切分一樣，我們也可以對數(shù)據(jù)庫通過一系列垂直和水平切分將數(shù)據(jù)分布到不同的DB服務器上，然后通過路由中間件訪問特定的數(shù)據(jù)庫。然而我們面臨的困難首先是網(wǎng)絡延時問題。因為原來依靠單機內部的通信現(xiàn)在要搬到外面來，成了機器與機器之間的通信，系統(tǒng)的開銷一下子因為網(wǎng)絡通信而增大。這種通信的代價會使系統(tǒng)單次提交的時間延遲。延遲提高會導致數(shù)據(jù)庫鎖定時間變長，使得性能比單機數(shù)據(jù)庫具有明顯差距。
分布式數(shù)據(jù)庫面臨的另一個問題是數(shù)據(jù)一致性問題。一致性就是數(shù)據(jù)保持一致，在分布式系統(tǒng)中，可以理解為多個節(jié)點中數(shù)據(jù)的值是一致的。而一致性又可以分為強一致性與弱一致性。強一致性就是在任意時刻，所有節(jié)點中的數(shù)據(jù)是一樣的。弱一致性又有很多種類型，目前分布式系統(tǒng)中廣泛實現(xiàn)的是最終一致性。所謂最終一致性，就是不保證在任意時刻任意節(jié)點上的同一份數(shù)據(jù)都是相同的，但是隨著時間的遷移，不同節(jié)點上的同一份數(shù)據(jù)總是在向趨同的方向變化。也可以簡單的理解為在一段時間后，節(jié)點間的數(shù)據(jù)會最終達到一致狀態(tài)。
這些問題恰恰是分布式數(shù)據(jù)庫的短板，就像它的可擴展性和可用性優(yōu)點一樣明顯。魚和熊掌不可兼得。根據(jù)著名的CAP理論，在分布式數(shù)據(jù)庫應用中，任何分布式系統(tǒng)只可同時滿足CAP其中兩點，無法三者兼顧。
- Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的；
- Availability(可用性), 好的響應性能，集群中某些節(jié)點宕掉了系統(tǒng)照用；
- Partition tolerance(分區(qū)容錯性) ，可靠性。系統(tǒng)如果不能在時限內達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當前操作在C和A之間做出選擇。
CA 系統(tǒng)是要求高可用并且實時一致性。單點數(shù)據(jù)庫是符合這種架構的。
AP 滿足可用性，分區(qū)容忍性的系統(tǒng)，通常可能對一致性要求低一些。
CP 系統(tǒng)是要求滿足一致性，分區(qū)容忍性，通常性能不是特別高。
我們不要將精力浪費在如何設計能滿足三者的完美分布式系統(tǒng)，而是應該進行取舍。所以分布式的數(shù)據(jù)庫也應該設計成多樣的。比如將分析類型應用所需要的數(shù)據(jù)遷移至以Hadoop為主的分布式NoSQL數(shù)據(jù)庫，將對實時一致性要求不是很高的一些應用遷移至分布式MySQL數(shù)據(jù)庫等。這里有必要提一下分布式關系型數(shù)據(jù)庫中的路由中間件。
數(shù)據(jù)庫中間件對數(shù)據(jù)庫云化改造或對整個IT架構的分布式改造起著非常重要的作用，它能提供的典型功能有分庫分表、讀寫分離、負載均衡、Failover 等。
跟阿里數(shù)據(jù)庫產品打過交道的人都知道它里面有個叫“頭都大了”（TDDL，Taobao Distributed Data Layer）的路由代理，用它可以大大簡化前端應用與后端數(shù)據(jù)庫的連接，特別是當應用和數(shù)據(jù)庫都成了分布式的時候，這是種N對N的連接。其實TDDL還并沒有全部開源，近兩年來有個在開源社區(qū)十分火爆的牛X產品叫“我的貓”（MyCat）。MyCat技術原理是它攔截了應用發(fā)送過來的SQL語句做特定分析：如分片分析、路由分析、讀寫分離分析、緩存分析等，然后將此SQL發(fā)往后端的數(shù)據(jù)庫節(jié)點，并將返回的結果做適當?shù)奶幚?，最終再返回給應用。MyCat發(fā)展到目前已經(jīng)不再是一個單純的MySQL代理了，它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流數(shù)據(jù)庫，也支持MongoDB這種新型NoSQL方式的存儲，未來還會支持更多類型的數(shù)據(jù)庫。
從用戶角度來看，代理中間件提供的就是一個傳統(tǒng)的數(shù)據(jù)庫表，支持標準的SQL語句，對前端業(yè)務系統(tǒng)來說，可以大幅降低開發(fā)難度，提升開發(fā)速度。對整個IT架構來說，因為這個中間件可以擁有一個多種數(shù)據(jù)庫的數(shù)據(jù)服務，拼在一起可以滿足CAP要求。
8. 結束語
X86、虛擬化、容器、分布式數(shù)據(jù)庫、微服務，所有這一切都是為了把我們的IT系統(tǒng)搭建起一個面向服務的架構，一個廣義上的SOA。其實前面把SOA簡單說成是做應用系統(tǒng)間的集成有失公允。因為當我們開發(fā)一個新應用時，也可以按照橫豎切分的原則來設計服務的開發(fā)，形成一個個應用組件，然后通過ESB開放給開發(fā)團隊使用。我所在的公司前幾年搞過一個叫做uCloud的PaaS項目，其設計理念就是上述思路的體現(xiàn)。在ESB之下，開發(fā)集成了十幾項技術服務和數(shù)據(jù)庫服務供應用方使用，一個典型的SOA架構。問題出在在這樣一個部門各自為政、應用開發(fā)以第三方廠家為主的公司，如果沒有一個強有力的管理措施要求各方必須使用中央管理的Service API時，結果自然可以想象。這令我不得不想起一個叫康威的老外定的一條規(guī)律：軟件設計的架構，實際上反應了公司的組織與溝通架構（Conway’ s law: Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations.）。
公司的組織與溝通是老板領導意識的最佳表現(xiàn)。所以服務化的成功與否不光光是中心化的SOA或去中心化的微服務選擇，更重要的是整個企業(yè)的一種戰(zhàn)略決策。最近微信群里流傳早在2002年，亞馬遜創(chuàng)始人兼CEO貝佐斯就在亞馬遜強制推行了以下六個原則：
- 所有團隊的程序模塊都要以通過Service Interface 方式將其數(shù)據(jù)與功能開放出來。
- 團隊間的程序模塊的信息通信，都要通過這些接口。
- 除此之外沒有其它的通信方式。其它形式一概不允許：不能使用直接鏈結程序、不能直接讀取其他團隊的數(shù)據(jù)庫、不能使用共享內存模式、不能使用別人模塊的后門、等等；唯一允許的通信方式只能是能過調用 Service Interface。
- 任何技術都可以使用。比如：HTTP、Corba、Pubsub、自定義的網(wǎng)絡協(xié)議、等等，都可以，貝佐斯不管這些。
- 所有的Service Interface，毫無例外，都必須從骨子里到表面上設計成能對外界開放的。也就是說，團隊必須做好規(guī)劃與設計，以便未來把接口開放給全世界的程序員，沒有任何例外。
- 不這樣的做的人會被炒魷魚。
十幾年后的亞馬遜已經(jīng)從一個購書網(wǎng)站發(fā)展成了全球最大的云公司，恐怕這也是和它的“服務化”戰(zhàn)略決策分不開的。貝佐斯的六原則展示出高度的遠見和超強的信念，“不謀萬世者，不足謀一時；不謀全局者，不足謀一域?！?/span>
從另一方面來看，SOA也好，微服務也好，虛擬化也好，容器也好，如果形不成一個公司的整體戰(zhàn)略，達到整個生態(tài)系統(tǒng)的共識，那么最好不要大張旗鼓地去搞什么全民皆兵的戰(zhàn)役。其結果往往以失敗而告終。當然謹慎地在自己的部門領域內做些新技術的嘗試性工作也未嘗不可，這種創(chuàng)新精神還是值得鼓勵的。
革命尚未成功，同志仍需努力。
- 全文完 -
