從阿里中臺發展史看IT架構轉型1——SOA與ESB

1、阿里共享業務事業部發展史

先簡而言之，提綱接領說下結論：

• 阿里的淘寶、天貓、1688等等業務擴張是IT架構演進的根本動力。
• 共享業務事業部能否存在，中臺能否立起來，技術能力不是核心。核心是組織/業務架構和績效考評方式，阿里中臺也是因把握了“聚划算”這一流量入口抓手，才把與電商部門不平等的話語權拉回平衡點。
• 持續需求->產品不斷迭代，才凸顯了統一中臺的重要性，否則各部門各幹個系統免不了。項目制的系統建設輕視運維，較難持續運維迭代系統。

• “大中臺、小前臺”的組織機制、業務機制建立起來，讓“大象也能跳舞”，有效減輕大公司病（決策審批可能慢，但執行層面效果提高了——公共與通用資源已建好，只需在前臺面向新方向做業務嘗試，一旦領導拍板就能重兵跟上）。

IT技術架構演進

也直接說我的理解和認識吧

• IT架構演進根本力量還是業務驅動，順帶着硬件、OS平臺廠商的升級推動。
• 小公司租用SaaS或建私有云SaaS是趨勢，集團類公司建中臺是趨勢。
• 煙囪式系統：各個業務線、部門有需求，領導批，就開建。主要針對本部門的需求，比如OA（流程審批、公文）、ERP | CRM（採購、報銷、合同、客戶）、HR（人員、考勤、薪酬福利）、項目管理等等，最多調研下相關部門需求。
  • 用戶、日誌、部門權限及部分業務功能不能複用，造成重複工作，操作員要多處維護
  • 系統間如需交互整合，不同廠商不同數據標準
  • 阿里的各條業務線基礎需求更近似（類似集團公司的幾個區域子公司），整合的需求更明顯
  • 項目制系統建設，容易讓各系統中實現的業務得不到沉澱和持續運營
• 分佈式架構：
  • 數據共享、業務協同是需求
  • 運維需求：2007年，淘寶已經擁有超過500人的技術團隊規模，整個淘寶網站是個幾百兆的war，大小功能200個。
  • 原各業務系統的能力不只侷限在本系統內，化作服務下沉到業務/數據中臺層（註冊到ESB上），爲更多業務應用提供支撐。
  • 信息技術部門“懂業務”不是從IT建設、系統架構層面講。而是站在組織業務發展角度看問題：業務流程如何進一步優化能更好的提升業務，現有業務能運用什麼更好的技術體系來支撐？
• 共享式架構：
  • https://blog.csdn.net/u014231523/article/details/86764420
  • https://blog.csdn.net/u014231523/article/details/86768731

SOA與ESB

星型結構是網狀結構的前身。SOA思維和ESB是不同層次的東西，ESB是SOA的一種實現方式，也是一種通用產品。

SOA

1. 松耦合的服務帶來業務的複用，通過服務的編排助力業務的快速響應和創新。
   1. 服務的組裝
   2. 服務註冊和自動發現
   3. 以服務契約方式定義服務交互方式
2. 核心價值是沉澱的這些服務，而不是應用層面實現多個系統間的集成。
3. 統一的核心服務能提供更穩定和高效，同時讓前端業務的信息和數據迴流到中臺。
4. 互聯網業務面向最大量的用戶，所以系統架構設計必須解決系統擴展性，網狀結構更符合需求。

ESB

1. 核心解決的是異構系統間的交互
2. “中心化”的星型結構，中等體量的業務是沒問題的。中心化比“點對點”的優勢，屏蔽了服務提供者服務接口變化造成的每個消費者都需要調整，現在只需在ESB上進行一次調整。
3. ESB提供了各種技術接口（HTTP、Socket、JDBC、JMS、REST、OGC...）的適配接入、數據格式轉換、數據裁剪、服務請求路由等功能。