轉載自Sammy Liu博客
0. 概況
時間：2019年2月23日 22:00~23:30
主題：企業IT架構
兄弟團：
孫杰（主持人）：中油瑞飛資深雲計算專家、架構師和運維專家，《企業私有云建設指南》作者
周健：業內資深雲計算專家
樓煒：雲星數據副總裁，業內資深雲計算專家
山金孝：業內資深雲計算專家，《OpenStack高可用架構》作者
肖力：新鈦雲服技術負責人，《深度實踐KVM》作者
北極熊：雲技術社區聯合創始人
劉世民：《世民談雲計算》博主
1. 一些跟企業IT架構相關的概念
1.1 微服務和SOA是什麼關係？
SOA 是面向服務架構的縮寫，它是一種架構理念。早期其主要形態是企業服務總線ESB（Enterprise Service Bus）。它主要是爲了滿足企業內多個異構業務系統之間的互聯互通需求。ESB提供了網絡中最基本的連接中樞，是構築企業神經系統的必要元素。ESB採用了“總線”這樣一種模式來管理和簡化應用之間的集成拓撲結構，以廣爲接受的開放標準爲基礎來支持應用之間在消息、事件和服務級別上動態的互連互通，是一種在鬆散耦合的服務和應用之間標準的集成方式。它可以作用於：
面向服務的架構—分佈式的應用由可重用的服務組成
面向消息的架構—應用之間通過ESB發送和接受消息
事件驅動的架構—應用之間異步地產生和接收消息
以ESB 在銀行中的應用爲例，
ESB的工作就是提供和調用集成系統的服務。使用了ESB，在大多情況下，每個系統和ESB之間，只需要定義一個訪問方法，一個接口。
但是，在互聯網架構下，ESB 出現了一些弊端，比如性能壓力。因爲ESB 本身也是單點，即使採用集羣部署，也無法完全解決性能問題。這時候微服務出現了。
可以認爲，微服務也是SOA理念的一種實現，它是一種新型面向服務的應用架構。它將一個應用分解爲多個服務，每個服務是獨立的，但服務之間又互相聯繫。其好處顯而易見，它本身所具備的可擴展性、可升級性、易維護性、故障和資源的隔離性等諸多特性使得產品的生產研發效率大大提高。因此，它能解決互聯網架構下高併發問題。
1.2. 爲什麼有 Kubernetes 還要有Service mesh？
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）方式。
1.3. PaaS 和 Serverless 之間是什麼關係？
關於 Serverless 是什麼，也就是它的定義，有很多的爭論，有很多不同的說法。
（1）有人認爲，serverless 是微服務架構之後的一種新IT架構形態，它把每個微服務再函數化。
從這個層面看，Serverless 是一種應用架構，而PaaS 只是這種架構的應用的一種運行平臺。
（2）還有觀點認爲，Serverless 是一種雲計算模型（execution model），其中，雲供應商動態地爲應用創建和管理服務器。一個 serverless 應用運行在無狀態容器中，是事件驅動的，由雲供應商完全託管。Serverless 根據執行的次數計費，而不是根據預先購買的計算容量計費。
從這個層面看，Serverless 是PaaS和SaaS之間的一個階段。
（3）從各大雲供應商提供的Serverless產品看，Serverless 目前的應用場景還比較有限，主要是一些事件驅動的運行時間較短的業務邏輯比較簡單的一些場景。
1.4 總結
以上分類主要是從技術層面進行的：
後一種架構的出現目的是爲了解決前一種架構的缺點和侷限性
應用架構和底層平臺之間具有聯繫，但兩者也不是強耦合關係
2. 企業業務中臺
普遍認爲，企業中臺可分爲技術中臺和業務中臺。
2.1 企業業務中臺是什麼
隨着阿里巴巴對其業務中臺的廣泛宣傳，以及業界對它的研究越來越深入，這個問題的答案已經比較清晰了。企業業務中臺就是把企業各個業務前臺系統中的公共部分抽取出來，變成共享業務服務，形成服務中臺，對前端的業務進行支撐。
2.2 企業業務中臺的目的
關於企業上業務中臺的主要目的，我們主要討論了以下幾點：
集團對業務加強管控的要求。在沒有企業業務中臺的時候，每個事業部（BU）各自控制的整個業務。比如每個BU都有自己的用戶中心、交易中心和評價中心等。但是，實際上，這些都是集團非常基礎性和根本性的東西。以電商行業爲例，用戶幾乎就是他們的命脈。因此，集團管理層要對整個集團的關鍵業務和數據進行管控。從這一點觸發，將這些業務抽取出來，進行統一管理，就比較順理成章了。可認爲這是一種政治需求。
新業務靈活性要求。在互聯網時代，企業要快速滿足用戶需求，實現以用戶爲中心，就要求其能快速推出新的滿足用戶新需求的業務系統。有了企業中臺提供的各種基礎性服務，企業就有可能快速象搭積木一樣構建出新的業務系統。這是一種業務需求。
業務系統技術架構優化要求。從技術架構師的角度出發，把各個業務系統中公共的模塊抽取出來，這本來就是一種常見的做法。這是技術需求。
2.3 企業業務中臺是企業一把手工程
上面三個業務有明顯的主次之分，那就是 集團管控要求 > 業務靈活性要求 > 技術架構要求。
也就是說，要上企業業務中臺，光靠企業的IT部門的推動，或者靠一兩個業務部門的推動，幾乎是不可能實現的任務。原因是因爲它涉及到衆多業務部門的利益重新分配。以前BU 可以獨立掌控其所有業務，而有了業務中臺後，BU 的很大一塊業務要被劃給他人了。因此，推進的時候往往收到各個BU的強大阻力。
再結合第一個需求，企業業務中臺只能由企業一把手來推動纔有可能。
從阿里巴巴最新一次組織架構調整情況來看，『阿里雲事業羣升級爲阿里雲智能事業羣，集團CTO張建鋒將兼任阿里雲智能事業羣總裁，直接向張勇彙報』。可以看出張建鋒兼任集團CTO（技術線）和阿里雲智能事業羣總裁（業務線）。阿里雲將來發展的重點方向，將由技術（平臺）轉到業務（中臺）。
3. 企業IT 架構
技術在不斷往前發展，但是技術爲業務服務的宗旨不會改變。企業業務狀態決定其企業IT系統的架構狀態。簡單來說：
傳統型業務只需要傳統架構的IT系統
互聯網業務需要互聯網架構的IT系統
3.1 企業業務特性決定了企業IT架構特徵
比如說，如果一個企業的互聯網業務佔比爲10%，那麼大致地，它所擁有的微服務IT系統的佔比也爲10%。
以銀行爲例，大部分銀行的核心業務系統還是在小機上。
企業IT架構演進主要是由業務和成本驅動。如果現有IT系統能支持當前業務，那麼改動的必要性就非常小。此時，穩定是第一需求。
3.2 不同企業架構的驅動角色是不同的
對基礎雲平臺來說，其主要需求及其特徵是：
通過虛擬化降低成本
通過集中管控降低成本
對現狀（用戶、開發團隊、應用系統、運維團隊等）的影響都比較小。
對PaaS平臺來說，其主要需求及其特徵是：
降低應用開發和運維成本
對開發流程、應用架構、團隊（項目團隊、運維團隊、開發團隊）的技能要求等都有較大影響。
對業務中臺來說，其主要需求及其特徵是：
集團對業務和數據的集中管控
業務標準化、靈活性和快速上線要求
業務系統架構優化
對業務部門的利益和企業組織結構都直接影響
3.3 一些啓發和要求
要給企業推廣什麼，一定要找到企業中能對它做決策的人。找錯人了，事情就沒戲了。
企業技術人員給企業領導寫材料講材料，要從業務而不是技術入手，否則老闆沒興趣往下聽。技術只有找到了業務需求點才有價值，否則就是技術人員的一廂情願。
企業技術人員要學習瞭解企業業務，從業務着手理解需求，然後再去設計業務系統。
參考資料：
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