全國熱線：010-62104249
地址：北京市密云區高嶺鎮政府辦公樓
王經理 13393261468
Q Q：514468705/1049705527
郵箱：jhcxkj@163.com
1)從 Function 到 Service
一、從函數說起
我是 1993 年學習電腦的。學習的開發語言有三種：匯編、C、DbaseIII。
所以在我學習的時候，我并不了解面向對象的代碼架構設計和代碼編程實現。所以要從字面上來區分函數和函數之間的關系，主要就靠函數命名、放在同一個代碼文件里、放在同一個代碼目錄文件夾里來區分他們之間的關聯性。
在當時函數時代，也沒啥異常保護、異常處理、異常日志的函數編寫基本原則，所以我們除了命名以外，主要注重的就是函數的輸入數據參數以及格式、輸出數據的參數以及格式。
二、面向對象
我的面向對象是用 Object Pascal 開始的，但真正大量寫面向對象代碼的時候是使用 Delphi，那已經是 1996 年的事情了。
因為有了類這個東西，所以函數就可以物以類聚了。有的函數屬于私有函數只能這個類里面才能調用，有的函數屬于公有函數可以供外部調用。
但是我那時候使用類還很初級，往往是一個源代碼文件中就定義一個類。而且類也沒有使用繼承，也就是說我所有的類都是平行的，類和類之間通過 Public 型的公開函數調用才產生了關系。
三、面向接口
Delphi 這個開發語言是優美的，它的定義申明和它的詳細實現是分離的。
業務功能進一步復雜起來了，過去沒什么太多關系的業務現在關系越來越緊密了，有些類和類之間的調用就太多了。我就想著重寫這塊代碼，把這兩個類進行合并了。但一重寫吧，需要動的東西太多了。
用繼承、用多重繼承的方法來做吧，太麻煩，總要在實現里寫一個空函數(就是沒有代碼但只有函數架子的，以備編譯器能語法通過)。后來認識了接口，就用接口定義了，就不使用空函數了，就定義，不實現，編譯器照樣能通過。
四、面向組件
我是完整經歷過面向組件時期的，并且用面向組件技術編寫過一整代完整的 ERP 引用套件。從 CORBA 技術到 COM/DCOM/COM+技術都嫻熟學習并使用過。我也是完整經歷單機版本到 C/S 客戶端服務器端局域網版本到 C/S/S 三層架構的。
一開始我用 DBaseIII 寫應用，UI 開發、業務邏輯開發、數據庫開發都是一個開發語言搞定。
后來用 Delphi 寫 C/S 應用，就用了 SQLServer 大型關系數據庫，在數據庫層就寫了不少存儲過程和定時 JOB 任務。但當時業務邏輯代碼和 UI 代碼都是運行在客戶端，所以這兩層之間的分離也并不清晰。
然后寫 C/S/S 三層架構，業務邏輯層獨立出來，而且是物理獨立部署，這樣客戶端代碼和業務邏輯層代碼就必須要徹底分開，不能不清不楚地混雜在一起了。在那個時候，我才開始大量使用精心的接口設計、對象設計。
因為有了獨立的業務邏輯層，那么這些代碼(接口/類)何時創建對象實例，何時釋放，這些對象實例要運行在哪個進程容器中，就有了要求了。因而就產生了組件容器和組件。組件容器來管理組件的全生命周期(安全、創建、并發訪問控制、休眠、激活喚醒、計數、摧毀釋放內存)，組件管理器就來管理組件的注冊、發現等。
所以《COM 本質論》的作者 Don Box 說.NET 就是更好的 COM，我一下子明白了：對啊，微軟的意思是，以后所有的應用都應該運行在組件容器中，不管是單機應用，還是 C/S 應用，還是 C/S/S 應用，每個應用都要運行在組件容器中，由組件容器來屏蔽和管理內存的創建與回收，不要把內存的創建與釋放直接袒露給開發者，否則開發者技術能力水平不一，有的爛的程序員管理不好內存，很容易就會使應用占滿內存并導致操作系統崩潰。
五、面向 WebService
哈哈哈，大家好像都沒聽說過面向 WebService，大家好像就聽過面向服務。
Web 互聯網興盛起來，HTML(UI 元素定義)+CSS(UI 元素風格定義)+JavaScript(UI 元素操作)構成了前端技術。人們又從前端里分離出來 XML，成為數據容器?？梢杂?HTTP+80 端口進行傳輸純文本的 XML 數據，也可以用 UDP、TCP/IP 等各種傳輸協議進行傳輸。當然，XML 還可以被壓縮以便更小尺寸在互聯網上傳輸(尤其過去互聯網速度很慢)，還可以被加密不讓人中間截獲看到。這些就構成了 WebService 的一個技術族。
我們現在要把局域網版本的 C/SS/三層技術架構，升級到 Web/S/S 三層技術架構，那怎么辦呢?
所以我們需要在我們的組件基礎上再包裝一層 WebService，客戶端的 AJAX 技術就好調用了。所以當時.NET 組件技術、EJB 技術、.NET 組件容器、EJB 組件容器中間件，都紛紛原生內嵌支持 WebService 技術族，讓從開發到運行到調用，直接就是 WebService 技術。這就是 SOA：面向服務架構。
(2)微服務
一、物極必反
當時是多么理想啊：一整套 J2EE 體系，WebService + EJB 完美組件模型 +WebLogic SOA 組件容器/ESB 組件管理器中間件，包括技術架構師。當年是多么多么大的市場啊。
但程序員是實用主義者，怎么簡單怎么來。隨著第二波互聯網創業熱崛起(2004 年)，大干快上才是王道，沒錢用開源開干才是王道。
于是，WebService 換成了 REST、XML 換成了 JSON、EJB 換成了普通的 JAVA Class、WebLogic 換成了開源的 Spring。尤其在 2004-2006 年，SSH 這三駕馬車(Structs 前端、Spring 中間層、Hibernate 數據層)真是橫行世界。
尤其 2004-2006，Google 崛起如日中天，Google 統一開放了自己的 Open API，輕的很。這已經是微服務流行的啟動了。但這時候還不能稱作微服務，可以稱作簡化服務(WebSerivce)。
二、亞馬遜的天條
貝索斯從 2002 年就親自制定了亞馬遜分布式系統架構六條原則：
所有團隊的程序模塊都要通過 WebService 接口將其數據與功能開放出來 團隊間程序模塊的信息通信，只能通過這些接口進行。其他形式一概不允許：不能用動態鏈接庫、不能讀取其他團隊數據庫、不能試用共享內存、不能試用別人模塊的后門，唯一允許的通信方式只有調用 WebService。 所有的 Web Service，毫無例外，都必須從骨子里到表面上都設計成能對外界開放的。也就是說，團隊必須做好規劃與設計，以便未來把接口開放給全世界的程序員，沒有任何例外 不這樣做的人會被炒魷魚 一個服務由一個小團隊(兩張披薩喂飽)負責，從前端到數據，從需求分銷到上線運維，全權負責 逆向工作法：先定義未來，然后發布新聞稿進行客戶探索與交互，再進行實現執行
我看到這六條原則，我也就明白了為啥亞馬遜能做成公有云計算領頭羊了，我也就明白了在現在 Cloud 大行其道的時候，亞馬遜還一直堅持使用 AWS 這個品牌(Amazon Web Service)。
我個人認為，從亞馬遜全職能小團隊、內外一體化原則開放 WebSevice 開始，服務才真正變小，成為微服務。如果你是個 100 人的團隊，你是一個按專業職能劃分的團隊，你是一個一年就發布 2 次的團隊，你是一個區分內部調用和外部調用的團隊，我相信，你是成不了真正的微服務的。你充其量來說，只能說，你是一個用了微服務技術卻沒有實現微服務的團隊。
這很好理解。很多程序員用了一輩子面向對象的開發語言，但從未自己定義過真正的類。這就是中國。
(3)云時代
一、移動時代來了
90 年代我們用 C/S，用 C/S/S Corba、DCOM/COM+，2000 年以后我們用.NET、EJB/WebLogic，后來我們又用 REST、JSON、Spring。這都是業務邏輯層技術的演進變化歷史。
在客戶端，倒是互聯網訪問速度越來越快費用越來越低、屏幕越來越大、性能越來越高、內存越來越大，給客戶呈現出來的功能越來越多、UI 界面越來越復雜。你這個時候想做微服務，其實蠻難的，你受不了誘惑，總想給它添加更多的功能，反正客戶端性能高、屏幕大，能承載，沒壞處。
但是移動時代從 2011 年在中國開始了。手機網速慢資費高、性能慢、內存小、屏幕小、沒有鍵盤和鼠標只能手指頭劃屏幕，所以微信從語音消息而非文字消息崛起了(打字輸入實在不好打啊)。
小屏幕，無鍵盤無鼠標，不好輸入也不好輸出，那么功能就必須簡化再簡化。這就倒逼業務邏輯層也不能做的太復雜。因此即使沒有亞馬遜開除人的六大天條轟頂，微服務在移動時代也算真正被大規模流行起來。現在小程序技術依托微信平臺(統一客戶、IM、支付)，讓開發、部署、發布更加簡化。
因為人人都有了隨時隨地可訪問的智能設備，所以企業比以往任何一個時代都能更容易連接、觸達、交互到最終消費者。所以企業應用開始從企業內部管控建設重心轉移到連接消費者、與消費者交互、消費者直接下單交易的業務重心。一個軟件的應用的使用主體從可以管控炒魷魚的員工，轉移到了給企業進行買單交易的衣食父母。
衣食父母不能得罪啊，這是要影響銷售業績的啊，所以需要抓住黏住、快速改進。所以為了快，而不要跨專業職能部門協作，所以各個研發團隊也都自行改組，從專業職能部門組織形式改造成為亞馬遜式的全職能小團隊，這更加助推了微服務的實質化落地。
所以，移動化限制倒逼、衣食父母倒逼，這是移動時代才讓大規模萬金油程序員學會落地微團隊、微項目、微功能、微服務。
二、云時代來了
因為企業應用重心已經從可數的企業員工用戶轉移到了大規模外界的消費者用戶，所以高性能并發、海量數據的技術要求立馬上來了。但企業應用開發者一直面對企業內部用戶規模，不是互聯網企業啊，怎么應對啊，沒經驗啊。
正好，云時代來了。
提供了分布式對象系統、分布式數據庫、分布式大數據技術平臺、分布式消息隊列中間件。當然，Spring 升級成了 Spring Cloud，成了分布式微服務中間件。噢耶，終于跨過這個技術門檻了。
別高興太早了。因為是分布式的，因為是面對海量最終消費者的，所以部署工作成了復雜的了。不像過去做企業內部管理應用，最多也就十來臺服務器，人手工都能升級得過來，而且企業員工一下班就能開干。現在都是消費者應用了，消費者都是行為習慣各異需要 24x7 運行，而且這還是交易型應用，你還不敢斷掉，你還不敢一下子全升級了你怕出個交易閃失賠不起錢，所以你還需要灰度發布。
這就需要工具了。
所以 DevOps 在互聯網時代、云計算時代才真正流行開。就是因為：海量用戶、在線 24x7 實時運行、交易型、大規模服務器、快速迭代開發發布上線，不得不開發運維一體化。過去運維人員的技術要求性不高，現在運維人員也得有開發技術能力了。
為了更快捷地打包、分發、部署、升級、維護，人們發明了 Docker 和 K8S。Docker 可以打包為一個鏡像文件、Docker 讓微服務的版本環境隔離、Docker 讓微服務在開發期和運行期一致，這讓分發、安裝部署、升級、運維變更極為簡化。
(4)云原生應用
一、微服務不微是因為什么
微服務不微，是很多人的困惑。
雖然有了全職能微團隊(2 張披薩餅)、微 UI(移動 APP 和小程序技術)、微項目(每兩周迭代發布一次)，但微服務仍然不微。
雖然有了滿足海量用戶高并發的 Spring Cloud 分布式微服務中間件、有了滿足分布式部署和運維的 DevOps(Jakins/Docker/k8s)，但微服務仍然不微。
問題到底出哪里了?
咱們從開發流程再捋一捋。
軟件公司嘛，軟件代碼是我們的核心資產。所以我們肯定有我們私有的 Git 源代碼庫，部署在我們公司的 IDC 機房里面，而且做層層的安全防護以及代碼備份機制。
我們要開發的時候，需要在我們本地安裝部署需要的各種框架，才能做本地開發、本地調試。但是現在為了應對高并發分布式中間件、海量大數據存儲與計算、人工智能訓練、物聯網接入，我們需要安裝的依賴的技術框架高達 40 多種以上。光部署調正常這堆框架已經把我們累的精疲力盡，而且這些框架之間隨便出點參數變更或版本不兼容問題就搞死人。
好，總算調正常這一堆框架，我們開發完具體業務應用，我們就開始應用 DevOps 工具和 Docker，進行打包、分發、部署。這么多依賴性的框架，你的微服務能微的了嗎?
二、云原生應用
正確的打開方式是什么呢?讓我們描繪一下。
第一步：你的代碼放在云代碼平臺而非你公司內部私有部署的 Git 平臺上。這就是微軟要花大價錢并購 Git 的原因。這是第一步。為什么要這樣做，你接下來就明白了。反正你現在基于云計算、大數據、人工智能、IOT 開發具體業務應用的時候，你大量依賴的都是開源平臺，就你那點具體業務應用能有多高技術門檻。而且微軟接手后的 git，對于企業代碼的安全保護、備份，比你自己的管理員和運維技術高多了。
第二步：使用云開發平臺。這個開發平臺可以基于 Web 瀏覽器，也可以基于本地 VS Code IDE，但云開發平臺的核心本質是：你根本不需要在本地安裝那么多依賴框架，你在 IDE 里面寫應用，你打開云上 Git 平臺上面的某個源代碼文件，import 進一個包，然后在 IDE 里直接調用 API，這個云開發平臺會自動補全 API，你可以保存代碼、你可以編譯代碼、你可以調試代碼、你可以運行代碼，和你本地一樣，但其實是應用運行在云端，應用也是在云端進行打包、安裝部署的。
這才是真正的云開發平臺，比如 AWS 的 Cloud9?，F在有很多李鬼，把 20 多年前雅奇 MIS 的那套玩法又拿了出來，快速可視化設計輸入表單，圖形化進行審批工作流設置，快速可視化設計報表圖表，這個東西在全世界也沒有獨立市場存在過，而且也不是今天我們談到的云原生應用開發路徑上的東西，或者換句話說，那根本不是給開發人員用的。
第三步：使用云服務OpenAPI。云計算廠商把所有的云服務都開放出來 Open API(你想想 Amazon 的六個天條)，你可以在這個云開發平臺上直接調用這個云計算廠商的所有 Open API 開放平臺里面的 API。這些云服務會自己負責自己的安裝部署升級、監控、備份、遷移等等。
三、終極：Serverless
最終極的方式是：Serverless。那個時代的 IaaS、技術 PaaS、應用 PaaS、具體業務應用 SaaS 很豐富，大家都開放 Open api，也有 Slack、企業微信、釘釘這樣的統一門戶平臺，也有小程序 UI 前端技術，你打開 Web IDE，New 一個函數，里面直接調用 Open API，你的應用功能就串聯起來了。
你也不用在意什么打包、安裝部署等細節。當你要運行時，在云端后臺，會自動啟用一整套 DevOps/Docker 工具集給你打包，會根據自己的云計算資源給你具體進行安裝與部署，你根本不用管是部署到哪個服務器上了。隨著你的應用性能，他會去給你自動遷移擴展到更高性能的計算環境中。這一切對于你來說都無感。你每月只需要繳納一筆總費用即可。
不這樣推，開發人員的效率提不上去;不這樣推，軟件公司只使用云廠商的云硬件資源，其他軟件中間件都自行開源部署而不使用云中間件，那樣云計算廠商也不容易掙大錢啊，畢竟硬件都是剛性成本，只有軟件才是高利潤的，尤其是云上部署的分布式中間件服務，更是大規模高利潤的。
來源：精密空調 http://lbjsjzl.com