1)從 Function 到 Service

一、從函數(shù)說起

我是 1993 年學(xué)習(xí)電腦的。學(xué)習(xí)的開發(fā)語言有三種：匯編、C、DbaseIII。

所以在我學(xué)習(xí)的時候，我并不了解面向?qū)ο蟮拇a架構(gòu)設(shè)計和代碼編程實現(xiàn)。所以要從字面上來區(qū)分函數(shù)和函數(shù)之間的關(guān)系，主要就靠函數(shù)命名、放在同一個代碼文件里、放在同一個代碼目錄文件夾里來區(qū)分他們之間的關(guān)聯(lián)性。

在當(dāng)時函數(shù)時代，也沒啥異常保護(hù)、異常處理、異常日志的函數(shù)編寫基本原則，所以我們除了命名以外，主要注重的就是函數(shù)的輸入數(shù)據(jù)參數(shù)以及格式、輸出數(shù)據(jù)的參數(shù)以及格式。

二、面向?qū)ο?/p>

我的面向?qū)ο笫怯?Object Pascal 開始的，但真正大量寫面向?qū)ο蟠a的時候是使用 Delphi，那已經(jīng)是 1996 年的事情了。

因為有了類這個東西，所以函數(shù)就可以物以類聚了。有的函數(shù)屬于私有函數(shù)只能這個類里面才能調(diào)用，有的函數(shù)屬于公有函數(shù)可以供外部調(diào)用。

但是我那時候使用類還很初級，往往是一個源代碼文件中就定義一個類。而且類也沒有使用繼承，也就是說我所有的類都是平行的，類和類之間通過 Public 型的公開函數(shù)調(diào)用才產(chǎn)生了關(guān)系。

三、面向接口

Delphi 這個開發(fā)語言是優(yōu)美的，它的定義申明和它的詳細(xì)實現(xiàn)是分離的。

業(yè)務(wù)功能進(jìn)一步復(fù)雜起來了，過去沒什么太多關(guān)系的業(yè)務(wù)現(xiàn)在關(guān)系越來越緊密了，有些類和類之間的調(diào)用就太多了。我就想著重寫這塊代碼，把這兩個類進(jìn)行合并了。但一重寫吧，需要動的東西太多了。

用繼承、用多重繼承的方法來做吧，太麻煩，總要在實現(xiàn)里寫一個空函數(shù)(就是沒有代碼但只有函數(shù)架子的，以備編譯器能語法通過)。后來認(rèn)識了接口，就用接口定義了，就不使用空函數(shù)了，就定義，不實現(xiàn)，編譯器照樣能通過。

四、面向組件

我是完整經(jīng)歷過面向組件時期的，并且用面向組件技術(shù)編寫過一整代完整的 ERP 引用套件。從 CORBA 技術(shù)到 COM/DCOM/COM+技術(shù)都嫻熟學(xué)習(xí)并使用過。我也是完整經(jīng)歷單機(jī)版本到 C/S 客戶端服務(wù)器端局域網(wǎng)版本到 C/S/S 三層架構(gòu)的。

一開始我用 DBaseIII 寫應(yīng)用，UI 開發(fā)、業(yè)務(wù)邏輯開發(fā)、數(shù)據(jù)庫開發(fā)都是一個開發(fā)語言搞定。

后來用 Delphi 寫 C/S 應(yīng)用，就用了 SQLServer 大型關(guān)系數(shù)據(jù)庫，在數(shù)據(jù)庫層就寫了不少存儲過程和定時 JOB 任務(wù)。但當(dāng)時業(yè)務(wù)邏輯代碼和 UI 代碼都是運(yùn)行在客戶端，所以這兩層之間的分離也并不清晰。

然后寫 C/S/S 三層架構(gòu)，業(yè)務(wù)邏輯層獨(dú)立出來，而且是物理獨(dú)立部署，這樣客戶端代碼和業(yè)務(wù)邏輯層代碼就必須要徹底分開，不能不清不楚地混雜在一起了。在那個時候，我才開始大量使用精心的接口設(shè)計、對象設(shè)計。

因為有了獨(dú)立的業(yè)務(wù)邏輯層，那么這些代碼(接口/類)何時創(chuàng)建對象實例，何時釋放，這些對象實例要運(yùn)行在哪個進(jìn)程容器中，就有了要求了。因而就產(chǎn)生了組件容器和組件。組件容器來管理組件的全生命周期(安全、創(chuàng)建、并發(fā)訪問控制、休眠、激活喚醒、計數(shù)、摧毀釋放內(nèi)存)，組件管理器就來管理組件的注冊、發(fā)現(xiàn)等。

所以《COM 本質(zhì)論》的作者 Don Box 說.NET 就是更好的 COM，我一下子明白了：對啊，微軟的意思是，以后所有的應(yīng)用都應(yīng)該運(yùn)行在組件容器中，不管是單機(jī)應(yīng)用，還是 C/S 應(yīng)用，還是 C/S/S 應(yīng)用，每個應(yīng)用都要運(yùn)行在組件容器中，由組件容器來屏蔽和管理內(nèi)存的創(chuàng)建與回收，不要把內(nèi)存的創(chuàng)建與釋放直接袒露給開發(fā)者，否則開發(fā)者技術(shù)能力水平不一，有的爛的程序員管理不好內(nèi)存，很容易就會使應(yīng)用占滿內(nèi)存并導(dǎo)致操作系統(tǒng)崩潰。

五、面向 WebService

哈哈哈，大家好像都沒聽說過面向 WebService，大家好像就聽過面向服務(wù)。

Web 互聯(lián)網(wǎng)興盛起來，HTML(UI 元素定義)+CSS(UI 元素風(fēng)格定義)+JavaScript(UI 元素操作)構(gòu)成了前端技術(shù)。人們又從前端里分離出來 XML，成為數(shù)據(jù)容器?？梢杂?HTTP+80 端口進(jìn)行傳輸純文本的 XML 數(shù)據(jù)，也可以用 UDP、TCP/IP 等各種傳輸協(xié)議進(jìn)行傳輸。當(dāng)然，XML 還可以被壓縮以便更小尺寸在互聯(lián)網(wǎng)上傳輸(尤其過去互聯(lián)網(wǎng)速度很慢)，還可以被加密不讓人中間截獲看到。這些就構(gòu)成了 WebService 的一個技術(shù)族。

我們現(xiàn)在要把局域網(wǎng)版本的 C/SS/三層技術(shù)架構(gòu)，升級到 Web/S/S 三層技術(shù)架構(gòu)，那怎么辦呢?

所以我們需要在我們的組件基礎(chǔ)上再包裝一層 WebService，客戶端的 AJAX 技術(shù)就好調(diào)用了。所以當(dāng)時.NET 組件技術(shù)、EJB 技術(shù)、.NET 組件容器、EJB 組件容器中間件，都紛紛原生內(nèi)嵌支持 WebService 技術(shù)族，讓從開發(fā)到運(yùn)行到調(diào)用，直接就是 WebService 技術(shù)。這就是 SOA：面向服務(wù)架構(gòu)。

(2)微服務(wù)

一、物極必反

當(dāng)時是多么理想啊：一整套 J2EE 體系，WebService + EJB 完美組件模型 +WebLogic SOA 組件容器/ESB 組件管理器中間件，包括技術(shù)架構(gòu)師。當(dāng)年是多么多么大的市場啊。

但程序員是實用主義者，怎么簡單怎么來。隨著第二波互聯(lián)網(wǎng)創(chuàng)業(yè)熱崛起(2004 年)，大干快上才是王道，沒錢用開源開干才是王道。

于是，WebService 換成了 REST、XML 換成了 JSON、EJB 換成了普通的 JAVA Class、WebLogic 換成了開源的 Spring。尤其在 2004-2006 年，SSH 這三駕馬車(Structs 前端、Spring 中間層、Hibernate 數(shù)據(jù)層)真是橫行世界。

尤其 2004-2006，Google 崛起如日中天，Google 統(tǒng)一開放了自己的 Open API，輕的很。這已經(jīng)是微服務(wù)流行的啟動了。但這時候還不能稱作微服務(wù)，可以稱作簡化服務(wù)(WebSerivce)。

二、亞馬遜的天條

貝索斯從 2002 年就親自制定了亞馬遜分布式系統(tǒng)架構(gòu)六條原則：

所有團(tuán)隊的程序模塊都要通過 WebService 接口將其數(shù)據(jù)與功能開放出來 團(tuán)隊間程序模塊的信息通信，只能通過這些接口進(jìn)行。其他形式一概不允許：不能用動態(tài)鏈接庫、不能讀取其他團(tuán)隊數(shù)據(jù)庫、不能試用共享內(nèi)存、不能試用別人模塊的后門，唯一允許的通信方式只有調(diào)用 WebService。 所有的 Web Service，毫無例外，都必須從骨子里到表面上都設(shè)計成能對外界開放的。也就是說，團(tuán)隊必須做好規(guī)劃與設(shè)計，以便未來把接口開放給全世界的程序員，沒有任何例外 不這樣做的人會被炒魷魚 一個服務(wù)由一個小團(tuán)隊(兩張披薩喂飽)負(fù)責(zé)，從前端到數(shù)據(jù)，從需求分銷到上線運(yùn)維，全權(quán)負(fù)責(zé) 逆向工作法：先定義未來，然后發(fā)布新聞稿進(jìn)行客戶探索與交互，再進(jìn)行實現(xiàn)執(zhí)行

我看到這六條原則，我也就明白了為啥亞馬遜能做成公有云計算領(lǐng)頭羊了，我也就明白了在現(xiàn)在 Cloud 大行其道的時候，亞馬遜還一直堅持使用 AWS 這個品牌(Amazon Web Service)。

我個人認(rèn)為，從亞馬遜全職能小團(tuán)隊、內(nèi)外一體化原則開放 WebSevice 開始，服務(wù)才真正變小，成為微服務(wù)。如果你是個 100 人的團(tuán)隊，你是一個按專業(yè)職能劃分的團(tuán)隊，你是一個一年就發(fā)布 2 次的團(tuán)隊，你是一個區(qū)分內(nèi)部調(diào)用和外部調(diào)用的團(tuán)隊，我相信，你是成不了真正的微服務(wù)的。你充其量來說，只能說，你是一個用了微服務(wù)技術(shù)卻沒有實現(xiàn)微服務(wù)的團(tuán)隊。

這很好理解。很多程序員用了一輩子面向?qū)ο蟮拈_發(fā)語言，但從未自己定義過真正的類。這就是中國。

(3)云時代

一、移動時代來了

90 年代我們用 C/S，用 C/S/S Corba、DCOM/COM+，2000 年以后我們用.NET、EJB/WebLogic，后來我們又用 REST、JSON、Spring。這都是業(yè)務(wù)邏輯層技術(shù)的演進(jìn)變化歷史。

在客戶端，倒是互聯(lián)網(wǎng)訪問速度越來越快費(fèi)用越來越低、屏幕越來越大、性能越來越高、內(nèi)存越來越大，給客戶呈現(xiàn)出來的功能越來越多、UI 界面越來越復(fù)雜。你這個時候想做微服務(wù)，其實蠻難的，你受不了誘惑，總想給它添加更多的功能，反正客戶端性能高、屏幕大，能承載，沒壞處。

但是移動時代從 2011 年在中國開始了。手機(jī)網(wǎng)速慢資費(fèi)高、性能慢、內(nèi)存小、屏幕小、沒有鍵盤和鼠標(biāo)只能手指頭劃屏幕，所以微信從語音消息而非文字消息崛起了(打字輸入實在不好打啊)。

小屏幕，無鍵盤無鼠標(biāo)，不好輸入也不好輸出，那么功能就必須簡化再簡化。這就倒逼業(yè)務(wù)邏輯層也不能做的太復(fù)雜。因此即使沒有亞馬遜開除人的六大天條轟頂，微服務(wù)在移動時代也算真正被大規(guī)模流行起來。現(xiàn)在小程序技術(shù)依托微信平臺(統(tǒng)一客戶、IM、支付)，讓開發(fā)、部署、發(fā)布更加簡化。

因為人人都有了隨時隨地可訪問的智能設(shè)備，所以企業(yè)比以往任何一個時代都能更容易連接、觸達(dá)、交互到最終消費(fèi)者。所以企業(yè)應(yīng)用開始從企業(yè)內(nèi)部管控建設(shè)重心轉(zhuǎn)移到連接消費(fèi)者、與消費(fèi)者交互、消費(fèi)者直接下單交易的業(yè)務(wù)重心。一個軟件的應(yīng)用的使用主體從可以管控炒魷魚的員工，轉(zhuǎn)移到了給企業(yè)進(jìn)行買單交易的衣食父母。

衣食父母不能得罪啊，這是要影響銷售業(yè)績的啊，所以需要抓住黏住、快速改進(jìn)。所以為了快，而不要跨專業(yè)職能部門協(xié)作，所以各個研發(fā)團(tuán)隊也都自行改組，從專業(yè)職能部門組織形式改造成為亞馬遜式的全職能小團(tuán)隊，這更加助推了微服務(wù)的實質(zhì)化落地。

所以，移動化限制倒逼、衣食父母倒逼，這是移動時代才讓大規(guī)模萬金油程序員學(xué)會落地微團(tuán)隊、微項目、微功能、微服務(wù)。

二、云時代來了

因為企業(yè)應(yīng)用重心已經(jīng)從可數(shù)的企業(yè)員工用戶轉(zhuǎn)移到了大規(guī)模外界的消費(fèi)者用戶，所以高性能并發(fā)、海量數(shù)據(jù)的技術(shù)要求立馬上來了。但企業(yè)應(yīng)用開發(fā)者一直面對企業(yè)內(nèi)部用戶規(guī)模，不是互聯(lián)網(wǎng)企業(yè)啊，怎么應(yīng)對啊，沒經(jīng)驗啊。

正好，云時代來了。

提供了分布式對象系統(tǒng)、分布式數(shù)據(jù)庫、分布式大數(shù)據(jù)技術(shù)平臺、分布式消息隊列中間件。當(dāng)然，Spring 升級成了 Spring Cloud，成了分布式微服務(wù)中間件。噢耶，終于跨過這個技術(shù)門檻了。

別高興太早了。因為是分布式的，因為是面對海量最終消費(fèi)者的，所以部署工作成了復(fù)雜的了。不像過去做企業(yè)內(nèi)部管理應(yīng)用，最多也就十來臺服務(wù)器，人手工都能升級得過來，而且企業(yè)員工一下班就能開干?，F(xiàn)在都是消費(fèi)者應(yīng)用了，消費(fèi)者都是行為習(xí)慣各異需要 24x7 運(yùn)行，而且這還是交易型應(yīng)用，你還不敢斷掉，你還不敢一下子全升級了你怕出個交易閃失賠不起錢，所以你還需要灰度發(fā)布。

這就需要工具了。

所以 DevOps 在互聯(lián)網(wǎng)時代、云計算時代才真正流行開。就是因為：海量用戶、在線 24x7 實時運(yùn)行、交易型、大規(guī)模服務(wù)器、快速迭代開發(fā)發(fā)布上線，不得不開發(fā)運(yùn)維一體化。過去運(yùn)維人員的技術(shù)要求性不高，現(xiàn)在運(yùn)維人員也得有開發(fā)技術(shù)能力了。

為了更快捷地打包、分發(fā)、部署、升級、維護(hù)，人們發(fā)明了 Docker 和 K8S。Docker 可以打包為一個鏡像文件、Docker 讓微服務(wù)的版本環(huán)境隔離、Docker 讓微服務(wù)在開發(fā)期和運(yùn)行期一致，這讓分發(fā)、安裝部署、升級、運(yùn)維變更極為簡化。

(4)云原生應(yīng)用

一、微服務(wù)不微是因為什么

微服務(wù)不微，是很多人的困惑。

雖然有了全職能微團(tuán)隊(2 張披薩餅)、微 UI(移動 APP 和小程序技術(shù))、微項目(每兩周迭代發(fā)布一次)，但微服務(wù)仍然不微。

雖然有了滿足海量用戶高并發(fā)的 Spring Cloud 分布式微服務(wù)中間件、有了滿足分布式部署和運(yùn)維的 DevOps(Jakins/Docker/k8s)，但微服務(wù)仍然不微。

問題到底出哪里了?

咱們從開發(fā)流程再捋一捋。

軟件公司嘛，軟件代碼是我們的核心資產(chǎn)。所以我們肯定有我們私有的 Git 源代碼庫，部署在我們公司的 IDC 機(jī)房里面，而且做層層的安全防護(hù)以及代碼備份機(jī)制。

我們要開發(fā)的時候，需要在我們本地安裝部署需要的各種框架，才能做本地開發(fā)、本地調(diào)試。但是現(xiàn)在為了應(yīng)對高并發(fā)分布式中間件、海量大數(shù)據(jù)存儲與計算、人工智能訓(xùn)練、物聯(lián)網(wǎng)接入，我們需要安裝的依賴的技術(shù)框架高達(dá) 40 多種以上。光部署調(diào)正常這堆框架已經(jīng)把我們累的精疲力盡，而且這些框架之間隨便出點(diǎn)參數(shù)變更或版本不兼容問題就搞死人。

好，總算調(diào)正常這一堆框架，我們開發(fā)完具體業(yè)務(wù)應(yīng)用，我們就開始應(yīng)用 DevOps 工具和 Docker，進(jìn)行打包、分發(fā)、部署。這么多依賴性的框架，你的微服務(wù)能微的了嗎?

二、云原生應(yīng)用

正確的打開方式是什么呢?讓我們描繪一下。

第一步：你的代碼放在云代碼平臺而非你公司內(nèi)部私有部署的 Git 平臺上。這就是微軟要花大價錢并購 Git 的原因。這是第一步。為什么要這樣做，你接下來就明白了。反正你現(xiàn)在基于云計算、大數(shù)據(jù)、人工智能、IOT 開發(fā)具體業(yè)務(wù)應(yīng)用的時候，你大量依賴的都是開源平臺，就你那點(diǎn)具體業(yè)務(wù)應(yīng)用能有多高技術(shù)門檻。而且微軟接手后的 git，對于企業(yè)代碼的安全保護(hù)、備份，比你自己的管理員和運(yùn)維技術(shù)高多了。

第二步：使用云開發(fā)平臺。這個開發(fā)平臺可以基于 Web 瀏覽器，也可以基于本地 VS Code IDE，但云開發(fā)平臺的核心本質(zhì)是：你根本不需要在本地安裝那么多依賴框架，你在 IDE 里面寫應(yīng)用，你打開云上 Git 平臺上面的某個源代碼文件，import 進(jìn)一個包，然后在 IDE 里直接調(diào)用 API，這個云開發(fā)平臺會自動補(bǔ)全 API，你可以保存代碼、你可以編譯代碼、你可以調(diào)試代碼、你可以運(yùn)行代碼，和你本地一樣，但其實是應(yīng)用運(yùn)行在云端，應(yīng)用也是在云端進(jìn)行打包、安裝部署的。

這才是真正的云開發(fā)平臺，比如 AWS 的 Cloud9。現(xiàn)在有很多李鬼，把 20 多年前雅奇 MIS 的那套玩法又拿了出來，快速可視化設(shè)計輸入表單，圖形化進(jìn)行審批工作流設(shè)置，快速可視化設(shè)計報表圖表，這個東西在全世界也沒有獨(dú)立市場存在過，而且也不是今天我們談到的云原生應(yīng)用開發(fā)路徑上的東西，或者換句話說，那根本不是給開發(fā)人員用的。

第三步：使用云服務(wù)OpenAPI。云計算廠商把所有的云服務(wù)都開放出來 Open API(你想想 Amazon 的六個天條)，你可以在這個云開發(fā)平臺上直接調(diào)用這個云計算廠商的所有 Open API 開放平臺里面的 API。這些云服務(wù)會自己負(fù)責(zé)自己的安裝部署升級、監(jiān)控、備份、遷移等等。

三、終極：Serverless

最終極的方式是：Serverless。那個時代的 IaaS、技術(shù) PaaS、應(yīng)用 PaaS、具體業(yè)務(wù)應(yīng)用 SaaS 很豐富，大家都開放 Open api，也有 Slack、企業(yè)微信、釘釘這樣的統(tǒng)一門戶平臺，也有小程序 UI 前端技術(shù)，你打開 Web IDE，New 一個函數(shù)，里面直接調(diào)用 Open API，你的應(yīng)用功能就串聯(lián)起來了。

你也不用在意什么打包、安裝部署等細(xì)節(jié)。當(dāng)你要運(yùn)行時，在云端后臺，會自動啟用一整套 DevOps/Docker 工具集給你打包，會根據(jù)自己的云計算資源給你具體進(jìn)行安裝與部署，你根本不用管是部署到哪個服務(wù)器上了。隨著你的應(yīng)用性能，他會去給你自動遷移擴(kuò)展到更高性能的計算環(huán)境中。這一切對于你來說都無感。你每月只需要繳納一筆總費(fèi)用即可。

不這樣推，開發(fā)人員的效率提不上去;不這樣推，軟件公司只使用云廠商的云硬件資源，其他軟件中間件都自行開源部署而不使用云中間件，那樣云計算廠商也不容易掙大錢啊，畢竟硬件都是剛性成本，只有軟件才是高利潤的，尤其是云上部署的分布式中間件服務(wù)，更是大規(guī)模高利潤的。

來源：精密空調(diào) http://mygoldentreasures.com

• 上一篇：云服務(wù)正成企業(yè)網(wǎng)絡(luò)流量的主導(dǎo)
• 下一篇：值得關(guān)注的5個多云重要趨勢
  
• 文章標(biāo)簽：
• 注：原創(chuàng)內(nèi)容，禁止轉(zhuǎn)載，如有轉(zhuǎn)載，請標(biāo)明出處。如有內(nèi)容侵犯您的權(quán)益，請聯(lián)系刪除！QQ:315212307