99久久亚洲一区二区三区青草,91色乱码一区二区三区,久久精品一区蜜桃臀影院,国产白丝在线观看

　　中臺按消費者（Consumer）調(diào)用的SLA來評價。比如一個模塊，在做之前，如何通過價值評價來決策做或者不做？

　　1、中臺本質(zhì)：企業(yè)架構治理

　　盡管如今已經(jīng)步入了Microservices與Cloud Native階段了，但如果不是一家游戲類、照片類、音視頻類純數(shù)字化公司（據(jù)我觀察，這類公司是最早采用云計算技術的），我推崇還是搞清楚早期Microsoft的一篇架構文檔中說明的三種架構層次。為什么？就像早期熟悉云計算架構必須看Amazon的技術白皮書一樣，作為企業(yè)服務領域的一哥，Microsoft的總結有極強的參考價值：

　　應用架構（Application Architecture），即系統(tǒng)技術架構，通常表現(xiàn)為帶有數(shù)據(jù)庫的三層/多層技術架構體系。

　　產(chǎn)品/項目架構（Product/Project Architecture），后期又稱之為解決方案架構（Solution Architecture），解決方案層與應用層的區(qū)別在于，它是業(yè)務導向的，致力于提升應用系統(tǒng)的業(yè)務質(zhì)量。

　　企業(yè)架構（Enterprise Architechture），它其實是一個規(guī)劃過程，識別企業(yè)IT未來應該達到的狀態(tài)，并實施一系列的計劃，使項目團隊通過交付達成。

　　中臺如何應對來自以用戶為中心的業(yè)務挑戰(zhàn)

　　以用戶為中心（Customer-centric）意味著向消費驅動的轉變。企業(yè)產(chǎn)品與服務的推出不再內(nèi)部可控，而是需要快速捕獲外部用戶的變化并響應用戶的需求。曾經(jīng)有客戶問：業(yè)務部門一年復一年人員都沒有增長，提需求的就是這些人，為啥我們的技術部門人員年年增長還不能完成需求？原因就在于：提需求的人是沒有增長，但提需求的節(jié)奏、頻率、變化都大大提升了。

　　2007年時還沒有Micoroservice架構，后來由Netflix在整合移動多屏及個性化時被實現(xiàn)。

　　中臺成功核心在于業(yè)務治理

　　Morgan在一篇文章《Adoption, rather than Architechure, is the high order bit for Architects》中指出，企業(yè)架構最重要的是組織對齊。“對齊”是國內(nèi)某家企業(yè)跨部門溝通最愛用的詞，也充分體現(xiàn)了該企業(yè)強大的組織能力。

　　中臺與ESB的核心差異是什么？在于業(yè)務服務能力（Capability）的下沉。ESB是消息總線，解決系統(tǒng)異構信息交換問題，而中臺集成的是各種服務提供方，解決業(yè)務能力共享的問題。中臺服務面向的顆粒度更細，更強調(diào)的是封裝完整的業(yè)務資源、邏輯和流程，每個服務有更強的自治性，而ESB的出現(xiàn)更單純地是為了解決系統(tǒng)層面的協(xié)作。比如說，早年企業(yè)針對銷售部門有一個訂單管理系統(tǒng)，后來針對售后部門又開發(fā)了一個服務管理系統(tǒng)，最后發(fā)現(xiàn)，售后需要回溯銷售合同的條款，一開始通過批量同步，還行；后面量大了，批量處理已經(jīng)延后了，就需要兩個系統(tǒng)更及時地同步。如果作為中臺架構師，在業(yè)務資源識別時，最徹底的就是面向客戶建立全生命周期的產(chǎn)品管理服務體系。早期的共享信息數(shù)據(jù)（SID）模型就是這樣的架構。

　　建設中臺或任何企業(yè)級中心化的系統(tǒng)，需要權衡的就是如何協(xié)調(diào)不同使用部門之間的利益點。比如說，某些部門不希望花費過多精力在系統(tǒng)建設上，那么組織提供的共享資源就很有用處；而某些部門希望能夠快速響應經(jīng)常變化、個性化的需求，那么組織級平臺就可能拖累他們的節(jié)奏；而還有一些部門根本就不想與其它系統(tǒng)有依賴，那這樣的共享服務對他們而言就沒有存在的必要。

　　中臺并不神秘，當企業(yè)想建設中臺時，首先應當考慮的是，業(yè)務部門的需求究竟是什么，他們希望改進什么方面？他們及涉及的利益相關者愿意為這個改進作出多大業(yè)務上的對齊？誰能夠承擔企業(yè)架構師的角色？很多架構師其實只是一個高級程序員，并不具備權衡（Tradeoffs）的能力和魄力。否則，這不應該成為中臺項目，更好的處理模式是在解決方案或應用層面尋找優(yōu)化措施。

　　早期的Connected Services Framework，在許多國外大型機構中演進成為Shared Services架構。

　　2、為什么你無法復制中臺？

　　阿里巴巴業(yè)務本身就是平臺型、開放型，但僅僅因為業(yè)務形態(tài)，也不足說明非平臺型公司不能建中臺，畢竟建成后效率更高啊。但企業(yè)需要意識到，阿里巴巴成功建設中臺，原因有兩點：第一，是對現(xiàn)有資源的整合而不是新建；第二，由內(nèi)部團隊驅動而不是外部公司承接。

　　可重用的資源

　　中臺普遍采用服務、API來集成提供業(yè)務能力，許多企業(yè)第一步就是欠缺的，沒有這些服務和API；通常我們說的“服務化”，意思是把現(xiàn)有的組件封裝為Web Service，以提供更強的復用能力，比如說，一個Java的組件，只有Java的程序能調(diào)用，但封裝為服務之后，PHP/Node.js/iOS/Android全都可以支持了，就極大地提升了后端程序的復用性。

　　但事實上去到企業(yè)一看，很多系統(tǒng)連組件邊界都不清晰，這個服務化，其實在幫助企業(yè)進行應用架構（Application Architecture）層面的模塊化梳理。許多企業(yè)連模塊化都不想做，就要一步上中臺，怎么辦，請外部公司空降PPT畫大餅、做培訓、倉促上馬半成品，結果可想而知。

　　運行維護和保障：你有工程能力來建設中臺嗎？

　　比如最簡單的一個問題，中臺上一個服務有多個消費者，如何進行版本升級？內(nèi)部組件如何做到灰度部署？如何回滾？事實是，關于服務要不要有版本編號，版本編號到底是不是一個值得采納的工程實踐，業(yè)界都還在踩坑、爭論。運轉中的中臺，復雜度超過一般的系統(tǒng)運行維護，沒有規(guī)范、沒有自動化、沒有云平臺管理能力的企業(yè)，很難玩轉中臺。即使空降一個中臺系統(tǒng)，落后的管理方式也只能將高鐵按照大巴時刻發(fā)車。

　　3、如何穩(wěn)步走向服務化戰(zhàn)略

　　茅臺這張PPT問題在哪里？在于沒有給出路徑。

　　與“中臺”這個名詞相比，我們還是更喜歡使用面向服務的戰(zhàn)略來表述以用戶為中心的未來IT架構轉變。

　　用戶驅動 顯性化中臺業(yè)務價值

　　更個性化、更快地響應最終用戶的請求，尤其是外部用戶的請求，應該是中臺構建的業(yè)務價值目標。如果中臺僅僅是優(yōu)化內(nèi)部業(yè)務，由于業(yè)務價值不明確，或難于衡量，將可能導致不及預期、難于協(xié)調(diào)一致多個部門，所以由外部用戶感知的業(yè)務價值驅動，更能有效地落地業(yè)務資源與流程的整合。

　　比如說，利用用戶旅程分析工具，將過去用戶需要面對多個業(yè)務人員的流程優(yōu)化為一項自助式服務，并支持在移動端、PC端和終端多處完成。定義用戶服務請求的監(jiān)控指標改進，包括業(yè)務處理時間、業(yè)務流量、交易量，等，即決定了此項優(yōu)化的業(yè)務價值。

　　團隊自治 構建高效面向業(yè)務服務的基層文化

　　如果你的團隊并不能真正理解服務化/中臺的好處，如此龐大的工程不可能真正落地。因為中心化的系統(tǒng)建設涉及的范圍太廣了，一條規(guī)范不能被正確執(zhí)行，都會留下后期調(diào)用的隱患。

　　讓過去涉及到多個業(yè)務協(xié)作的系統(tǒng)團隊進行合作，設計出新的解決方案，讓他們直接面向業(yè)務部門收集的反饋，或用戶使用的行為指標、報告作出響應。

　　如果發(fā)現(xiàn)在這個團隊中，他們依然還需要依賴第三方的人、系統(tǒng)來解決問題，那么自治式還不夠好，需要進一步解除依賴。雖然這在許多金融機構聽起來不太可能，但如果這些問題都解決不了，誰又能真正承諾最終交付的中臺服務能夠高效響應呢？

　　服務管理 一步步加強中心團隊治理能力

　　隨著服務越來越多，需要有專門的服務管理團隊，接手服務基礎設施、目錄，并完善監(jiān)控和運營治理。可以為服務管理團隊設立服務規(guī)劃部門，一步一步為企業(yè)的服務化/中臺戰(zhàn)略進行未來狀態(tài)的導引。

　　總結

　　中臺不是一個新事物，也并不神秘。重視中臺，說明中國的企業(yè)開始意識到企業(yè)架構帶來的巨大能效優(yōu)勢，供我們制定更加合理的轉型提速節(jié)奏。