簡介：本文作者來自於中國人壽保險股份有限公司研發中心，對企業數字化轉型、雲原生實踐有比較資深的經驗。以下內容整理自作者對最新出版的《阿里云云原生架構實踐》的讀後感。

作者｜肖晟

​

本文作者來自於中國人壽保險股份有限公司研發中心，對企業數字化轉型、雲原生實踐有比較資深的經驗。以下內容整理自作者對最新出版的《阿里云云原生架構實踐》的讀後感。

初心

​

作為金融行業的 IT 從業者，參與著傳統企業數字化轉型程序，我們一直在思考兩個問題：一是什麼是數字化，為什麼要數字化？二是如何推進數字化轉型，路徑、工具、組織等方面該如何規劃調整？
​

大家常常會混淆資訊化與數字化的概念，以為上線了一些業務系統或是投放了一些數字大盤，就完成了 IT 建設目標。但實際上這可能只是改變了一些資訊資料向領導層流轉的形式，整個業務的工作模式並沒有什麼變化；原來需要人工操作的依然需要人工操作，該走的流程還得接著走（甚至新建的系統還新增了一些流程），效率沒有明顯變化；企業的業績是否有提升，若有提升那與 IT 建設是否正相關，價效比是否划算等等，這些往往也缺乏有效的評價方式，很容易陷入偽數字化的坑。
​

“
任何架構都必須服務於企業戰略，雲原生架構也不例外！

企業必須清楚業務戰略與雲 IT 戰略之間的關係，即雲IT戰略只是對業務戰略進行必要的技術支撐，還是雲 IT 戰略本身也是業務戰略的一部分。
”
​

非常贊同《阿里云云原生架構實踐》一書中提到的觀點，技術終歸是服務於企業價值的。因此，我們認為，數字化是基於資訊化的能力改進業務模式，聚合全價值鏈上的各個環節和資料，把著力點放在指導業務運營和決策上；最終表現形式，就是“全量全要素資料+自動化+實時化”的智慧形態。

“
數字化業務對技術架構的主要訴求是保證業務連續性、業務快速上線、業務成本控制，以及科技賦能業務創新。
”
​

為了讓業務開發團隊能夠更快更穩的進行高質量交付，以滿足越來越快的業務需求，“小前端、大中臺/大後端”是必選之路。因為只有讓前端更輕，業務開發團隊才能更聚焦業務，交付也才能更敏捷；而中臺和後端做重一點，高質量的設計與規範都沉澱其中，其中的最佳實踐複用度也就更高。
​

核心思想可以用一個詞概括——“下沉”。
​

當我們把公共技術能力與方法下沉到開發框架、下沉到基礎平臺、下沉到自動化的規範流程中，基於這些能力構建的應用就可以很敏捷了，且生來就處於一個高質量的架構體系中（正所謂贏在起跑線上），而云原生架構是這種能力下沉落地的最佳實踐方法論。
​

出發

​

“
雲原生架構是基於雲原生技術的一組架構原則和設計模式的集合，旨在幫助企業和開發人員充分利用雲平臺所提供的平臺化能力和彈性資源能力。

雲原生包括雲原生技術、雲原生產品、雲原生架構以及構建現代化應用的開發理念。
”
​

現代化應用和雲原生應用是基於雲原生的架構和開發理念構建或實現的，如服務化原則、彈性原則等 7 大架構原則，計算儲存分離模式、事件驅動模式等 10 種架構模式，以及 DevOps、GitOps 等研發理念。
​

雲原生架構和雲原生開發理念是基於雲原生技術和產品構建或實現的，包括容器技術、DevOps 技術、微服務、Service Mesh、Serverless、雲原生大資料、雲原生AI、雲原生安全等十餘項技術和產品。其中，開放應用模型（Open Application Model，OAM）的概念讓人耳目一新，將 PaaS 中對資源的標準化宣告拓展到對應用、配置的標準化宣告，“讓簡單的應用程式變得更簡單，讓複雜的應用程式更易於管理”。
​

最後，雲原生產品和雲原生技術又是需要基於公有云、私有云或混合雲的雲基礎設施。雲原生的組成，就是如此層層遞進的關係。
​

走過的路

​

“
雲原生架構升級是對企業的整個IT架構的徹底升級，每個組織在進行雲原生架構升級時，必須根據企業自身的情況量體裁衣，其中，組織能力和技術棧處於同等重要的地位。
”
在數字化轉型的道路上，傳統企業的歷史包袱著實不小，在不能停業務的情況下進行架構改造無異於給飛行中的飛機換髮動機、換操作流程，乃至換機組人員。
​

筆者來自於中國人壽保險股份有限公司，親身經歷過一個服務化技術升級的案例，是不得已的情況下，雲原生技術給了我們新的答案。
​

IT 建設初期，煙囪式系統林立；隨著系統越來越多，系統間互動需求越來越大，服務化需求被提上議程，十多年前，以匯流排型架構為代表 SOA 理念風靡，各系統紛紛對接服務匯流排。但隨著移動網際網路的興起，服務壓力逐年倍增，匯流排型架構的瓶頸逐步顯現了出來，匯流排的一個抖動很容易造成各類服務的阻塞，微服務架構的引入更加劇了這種現象。
​

此時，服務註冊發現模式已然成熟，新建系統均採用 Spring Cloud 及類似產品來實施，但既有系統卻無法採用這種侵入性很強的方式來改造，成本高、風險大；而且多程式語言開始出現，不同語言間要實現相同的服務治理也很困難。我們一籌莫展，只能艱難的維護著服務匯流排，儘量從架構層面提升它的健壯性。直到幾年前聽聞服務網格的概念，準確說是非侵入式的 SideCar 模式，我們意識到答案來了。目前，我們正在全面網格化的程序中。
​

SideCar 模式本身並不是新鮮事，但為何近些年又火起來了？歸根到底，還是容器技術、DevOps 等雲原生技術的成熟，解決了海量 SideCar 運維成本與效率的問題。所以，雲原生技術本身也是講究時機、相輔相成的，而我們作為應用方則順勢而為，“打破原穩態並構建新穩態”。
​

“
此外，雲原生架構的設計還需要考慮組織結構的改變。前面提到一個非常重要的雲原生架構原則就是服務化（包括微服務、小服務等），這個領域的一個典型原則就是康威定律，要求企業的技術架構與溝通架構必須保持一致，否則會導致畸形的服務化架構，甚至導致組織溝通成本上升和“扯皮”現象增多的問題。
”
任何方案的落地，人都是第一要素。給新同事上技術課或是做架構分享的時候，都會提到康威定律。產品的結構就是組織結構的縮影，再大白話一些就是“屁股決定腦袋”。推行一些技術架構或管理流程，組織架構都是繞不過去的坎；在不對組織架構做重大調整的情況下，我們選擇的方案不一定是最理想的，而是在當前組織架構下最合適的。
​

至於我們自身，則需要時刻提醒自己，跳出組織架構給我們劃定的圈子，從全流程、全場景、更高的層面來看待問題、思考方案。
​

自己的路

​

“
但是，有一點需要注意，包括 AWS 、阿里雲、微軟等在內的雲端計算服務公司，都沒有完全按照這些軟體架構標準來構建其雲服務的軟體架構體系。這完全不是出於偶然，因為這些公司充分意識到，基於雲端計算的軟體架構應該是一種適用於非中心化組織的軟體架構，而不是傳統的基於中心化組織的軟體架構。所以，傳統的軟體架構標準對於雲原生架構而言，需要進一步定製和裁剪，才能更好地發揮價值。軟體架構設計模式會有傳統軟體架構設計方法用到的利益關注點，但是在具體設計方法上又有所不同。
”
​

當然，有了一張地圖，並不代表就不會迷路了。上至企業，下至團隊，每個組織都有自己的痛點和訴求，也有相應的文化和優勢。在選對方向之後，具體落地還得探索符合企業自身特色的道路，這是需要不斷實踐和試錯的。阿里 ACNA 架構設計方法及其成熟度模型評價體系，可作為數字化轉型中技術架構演程序度及效果的參考。

“
企業的技術戰略逐漸向業務架構及其治理方向轉移”。隨著 DevOps 的深化普及，應用交付流程將會更加標準化。而云服務型別的增多也將催生新的開發模式和開發框架。
”
最後，還是想強調歸回初心。技術服務於企業價值，綜合評估投資回報率，最終實現幫助企業降本增效，降低風險，提升體驗的效果。

原文連結

本文為阿里雲原創內容，未經允許不得轉載。