時間:2019年2月23日 22:00~23:30html
主題:企業IT架構前端
兄弟團:java
孫杰(主持人):中油瑞飛資深雲計算專家、架構師和運維專家,《企業私有云建設指南》做者安全
周健:業內資深雲計算專家服務器
樓煒:雲星數據副總裁,業內資深雲計算專家網絡
山金孝:業內資深雲計算專家,《OpenStack高可用架構》做者架構
肖力:新鈦雲服技術負責人,《深度實踐KVM》做者併發
北極熊:雲技術社區聯合創始人less
劉世民:《世民談雲計算》博主 運維
SOA 是面向服務架構的縮寫,它是一種架構理念。早期其主要形態是企業服務總線ESB(Enterprise Service Bus)。它主要是爲了知足企業內多個異構業務系統之間的互聯互通需求。ESB提供了網絡中最基本的鏈接中樞,是構築企業神經系統的必要元素。ESB採用了「總線」這樣一種模式來管理和簡化應用之間的集成拓撲結構,以廣爲接受的開放標準爲基礎來支持應用之間在消息、事件和服務級別上動態的互連互通,是一種在鬆散耦合的服務和應用之間標準的集成方式。它能夠做用於:
面向服務的架構—分佈式的應用由可重用的服務組成
面向消息的架構—應用之間經過ESB發送和接受消息
事件驅動的架構—應用之間異步地產生和接收消息
以ESB 在銀行中的應用爲例,
ESB的工做就是提供和調用集成系統的服務。使用了ESB,在大多狀況下,每一個系統和ESB之間,只須要定義一個訪問方法,一個接口。
可是,在互聯網架構下,ESB 出現了一些弊端,好比性能壓力。由於ESB 自己也是單點,即便採用集羣部署,也沒法徹底解決性能問題。這時候微服務出現了。
能夠認爲,微服務也是SOA理念的一種實現,它是一種新型面向服務的應用架構。它將一個應用分解爲多個服務,每一個服務是獨立的,但服務之間又互相聯繫。其好處顯而易見,它自己所具有的可擴展性、可升級性、易維護性、故障和資源的隔離性等諸多特性使得產品的生產研發效率大大提升。所以,它能解決互聯網架構下高併發問題。
Chris Richardson 曾指出:「微服務應用是分佈式系統,由此會帶來固有的複雜性。開發者須要在 RPC 或者消息傳遞之間選擇並完成進程間通信機制。此外,他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。」
在雲原生模型裏,一個應用能夠由數百個服務組成,每一個服務可能有數千個實例,而每一個實例可能會持續地發生變化。這種狀況下,服務間通訊不只異常複雜,並且也是運行時行爲的基礎。管理好服務間通訊對於保證端到端的性能和可靠性來講是無疑是很是重要的。
以上種種複雜局面便催生了服務間通訊層的出現,這個層既不會與應用程序的代碼耦合,又能捕捉到底層環境高度動態的特色,讓業務開發者只關注本身的業務代碼,並將應用雲化後帶來的諸多問題以不侵入業務代碼的方式提供給開發者。
這個服務間通訊層就是 Service Mesh,它能夠提供安全、快速、可靠的服務間通信(service-to-service)。
所以,Service mesh 也是一種微服務架構理念,它把微服務的業務邏輯層和微服務通訊層進行解耦。應用開發者專一於業務邏輯,而服務網格則來解決通訊層問題。
Service mesh 所實現的基礎設施層,每每分爲控制平臺(control plane)和數據平面(data plane)。控制平面用於控制基礎設施,而數據平臺用於實現網絡通訊能力。同時,有多種Servcie mesh 的實現方式,而邊車(sidecar)是比較主流的一種。
Service mesh 並非 Kubernetes 的特有產物,而是微服務架構自身的需求。Kubernetes 是一種運行微服務的平臺,它使用容器運行微服務,主要提供容器編排能力。istio 是面向Kuberntes 的一種 Service mesh 實現,它採用邊車(sidecar)方式。
關於 Serverless 是什麼,也就是它的定義,有不少的爭論,有不少不一樣的說法。
(1)有人認爲,serverless 是微服務架構以後的一種新IT架構形態,它把每一個微服務再函數化。
從這個層面看,Serverless 是一種應用架構,而PaaS 只是這種架構的應用的一種運行平臺。
(2)還有觀點認爲,Serverless 是一種雲計算模型(execution model),其中,雲供應商動態地爲應用建立和管理服務器。一個 serverless 應用運行在無狀態容器中,是事件驅動的,由雲供應商徹底託管。Serverless 根據執行的次數計費,而不是根據預先購買的計算容量計費。
從這個層面看,Serverless 是PaaS和SaaS之間的一個階段。
(3)從各大雲供應商提供的Serverless產品看,Serverless 目前的應用場景還比較有限,主要是一些事件驅動的運行時間較短的業務邏輯比較簡單的一些場景。
以上分類主要是從技術層面進行的:
後一種架構的出現目的是爲了解決前一種架構的缺點和侷限性
應用架構和底層平臺之間具備聯繫,但二者也不是強耦合關係
廣泛認爲,企業中臺可分爲技術中臺和業務中臺。
隨着阿里巴巴對其業務中臺的普遍宣傳,以及業界對它的研究愈來愈深刻,這個問題的答案已經比較清晰了。企業業務中臺就是把企業各個業務前臺系統中的公共部分抽取出來,變成共享業務服務,造成服務中臺,對前端的業務進行支撐。
關於企業上業務中臺的主要目的,咱們主要討論瞭如下幾點:
集團對業務增強管控的要求。在沒有企業業務中臺的時候,每一個事業部(BU)各自控制的整個業務。好比每一個BU都有本身的用戶中心、交易中心和評價中心等。可是,實際上,這些都是集團很是基礎性和根本性的東西。以電商行業爲例,用戶幾乎就是他們的命脈。所以,集團管理層要對整個集團的關鍵業務和數據進行管控。從這一點觸發,將這些業務抽取出來,進行統一管理,就比較瓜熟蒂落了。可認爲這是一種政治需求。
新業務靈活性要求。在互聯網時代,企業要快速知足用戶需求,實現以用戶爲中心,就要求其能快速推出新的知足用戶新需求的業務系統。有了企業中臺提供的各類基礎性服務,企業就有可能快速象搭積木同樣構建出新的業務系統。這是一種業務需求。
業務系統技術架構優化要求。從技術架構師的角度出發,把各個業務系統中公共的模塊抽取出來,這原本就是一種常見的作法。這是技術需求。
上面三個業務有明顯的主次之分,那就是 集團管控要求 > 業務靈活性要求 > 技術架構要求。
也就是說,要上企業業務中臺,光靠企業的IT部門的推進,或者靠一兩個業務部門的推進,幾乎是不可能實現的任務。緣由是由於它涉及到衆多業務部門的利益從新分配。之前BU 能夠獨立掌控其全部業務,而有了業務中臺後,BU 的很大一塊業務要被劃給他人了。所以,推動的時候每每收到各個BU的強大阻力。
再結合第一個需求,企業業務中臺只能由企業一把手來推進纔有可能。
從阿里巴巴最新一次組織架構調整狀況來看,『阿里雲事業羣升級爲阿里雲智能事業羣,集團CTO張建鋒將兼任阿里雲智能事業羣總裁,直接向張勇彙報』。能夠看出張建鋒兼任集團CTO(技術線)和阿里雲智能事業羣總裁(業務線)。阿里雲未來發展的重點方向,將由技術(平臺)轉到業務(中臺)。
技術在不斷往前發展,可是技術爲業務服務的宗旨不會改變。企業業務狀態決定其企業IT系統的架構狀態。簡單來講:
傳統型業務只須要傳統架構的IT系統
互聯網業務須要互聯網架構的IT系統
好比說,若是一個企業的互聯網業務佔比爲10%,那麼大體地,它所擁有的微服務IT系統的佔比也爲10%。
以銀行爲例,大部分銀行的核心業務系統仍是在小機上。
企業IT架構演進主要是由業務和成本驅動。若是現有IT系統能支持當前業務,那麼改動的必要性就很是小。此時,穩定是第一需求。
對基礎雲平臺來講,其主要需求及其特徵是:
經過虛擬化下降成本
經過集中管控下降成本
對現狀(用戶、開發團隊、應用系統、運維團隊等)的影響都比較小。
對PaaS平臺來講,其主要需求及其特徵是:
下降應用開發和運維成本
對開發流程、應用架構、團隊(項目團隊、運維團隊、開發團隊)的技能要求等都有較大影響。
對業務中臺來講,其主要需求及其特徵是:
集團對業務和數據的集中管控
業務標準化、靈活性和快速上線要求
業務系統架構優化
對業務部門的利益和企業組織結構都直接影響
要給企業推廣什麼,必定要找到企業中能對它作決策的人。找錯人了,事情就沒戲了。
企業技術人員給企業領導寫材料講材料,要從業務而不是技術入手,不然老闆沒興趣往下聽。技術只有找到了業務需求點纔有價值,不然就是技術人員的一廂情願。
企業技術人員要學習瞭解企業業務,從業務着手理解需求,而後再去設計業務系統。
參考資料:
https://zato.io/docs/intro/esb-soa-cn.html
https://www.cnblogs.com/zdz8207/p/java-esb.html
https://www.infoq.cn/article/2017%2F12%2Fwhy-service-mesh
https://medium.com/@johncmckim/the-debate-over-what-is-serverless-d8e179449d1b