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 代碼都是運行在客戶端,，所以這兩層之間的分離也并不清晰,。

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

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

所以《COM 本質(zhì)論》的作者 Don Box 說.NET 就是更好的 COM,，我一下子明白了：對啊，微軟的意思是,，以后所有的應(yīng)用都應(yīng)該運行在組件容器中,，不管是單機(jī)應(yīng)用，還是 C/S 應(yīng)用,，還是 C/S/S 應(yīng)用,，每個應(yīng)用都要運行在組件容器中，由組件容器來屏蔽和管理內(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ā)到運行到調(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ù)，從需求分銷到上線運維,，全權(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)訪問速度越來越快費用越來越低、屏幕越來越大,、性能越來越高,、內(nèi)存越來越大，給客戶呈現(xiàn)出來的功能越來越多,、UI 界面越來越復(fù)雜,。你這個時候想做微服務(wù)，其實蠻難的,，你受不了誘惑,，總想給它添加更多的功能，反正客戶端性能高,、屏幕大,，能承載，沒壞處,。

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

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

因為人人都有了隨時隨地可訪問的智能設(shè)備,，所以企業(yè)比以往任何一個時代都能更容易連接,、觸達(dá)、交互到最終消費者,。所以企業(yè)應(yīng)用開始從企業(yè)內(nèi)部管控建設(shè)重心轉(zhuǎn)移到連接消費者,、與消費者交互、消費者直接下單交易的業(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ā),、海量數(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ù)雜的了,。不像過去做企業(yè)內(nèi)部管理應(yīng)用，最多也就十來臺服務(wù)器,，人手工都能升級得過來,，而且企業(yè)員工一下班就能開干。現(xiàn)在都是消費者應(yīng)用了,，消費者都是行為習(xí)慣各異需要 24x7 運行,，而且這還是交易型應(yīng)用，你還不敢斷掉,，你還不敢一下子全升級了你怕出個交易閃失賠不起錢,，所以你還需要灰度發(fā)布。

這就需要工具了,。

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

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

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

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

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

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

雖然有了滿足海量用戶高并發(fā)的 Spring Cloud 分布式微服務(wù)中間件,、有了滿足分布式部署和運維的 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)把我們累的精疲力盡,，而且這些框架之間隨便出點參數(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)用的時候，你大量依賴的都是開源平臺,，就你那點具體業(yè)務(wù)應(yīng)用能有多高技術(shù)門檻,。而且微軟接手后的 git，對于企業(yè)代碼的安全保護(hù),、備份,，比你自己的管理員和運維技術(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īng)用運行在云端，應(yīng)用也是在云端進(jìn)行打包,、安裝部署的,。

這才是真正的云開發(fā)平臺，比如 AWS 的 Cloud9?，F(xiàn)在有很多李鬼,，把 20 多年前雅奇 MIS 的那套玩法又拿了出來，快速可視化設(shè)計輸入表單，圖形化進(jìn)行審批工作流設(shè)置,，快速可視化設(shè)計報表圖表,，這個東西在全世界也沒有獨立市場存在過，而且也不是今天我們談到的云原生應(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)你要運行時,，在云端后臺，會自動啟用一整套 DevOps/Docker 工具集給你打包,，會根據(jù)自己的云計算資源給你具體進(jìn)行安裝與部署,，你根本不用管是部署到哪個服務(wù)器上了。隨著你的應(yīng)用性能,，他會去給你自動遷移擴(kuò)展到更高性能的計算環(huán)境中,。這一切對于你來說都無感。你每月只需要繳納一筆總費用即可。

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

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

• 上一篇：云服務(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