什麼叫做微服務？這是Martin提出來的一個概念，它是一種將應用構建成一系列按業務領域劃分模組的，小的自治服務的軟體架構方式，倡導將複雜的單體應用拆分成若干個功能單一、松偶合的服務，這樣可以降低開發難度、增強擴充套件性、便於敏捷開發，及持續整合與交付活動。如何界定：小、獨，還有要做一個事情，完成單一的業務，單一的功能要拆分出來，因為如果耦合在一起就影響到另外一個模組，還有就是持續互動和敏捷，怎麼去定義？多大算小？亞馬遜以及國外的架構師由2—Pizza團隊端到端負責一個或一組服務，大小是合適的，區別於傳統單體應用，各個模組、元件或動態庫整合在一個大程序中的執行。剛剛張老師分享網際網路架構原來的技術和轉型，我想講一下微服務架構在傳統企業裡面特別明顯，原來傳統的IOE架構是什麼樣的？所有的應用最開始在IOE時代業務應用和資料庫是在一起的，它的特點是什麼？我的業務邏輯只會跟資料庫互動，所有的複雜東西我把我的複雜邏輯在資料庫內解決了，每個都是單一的，業務之間比較龐大，現在有很多公司在使用第二種架構方式，就是SOA的架構，它已經微服務化了，但是它的特點是呼叫和服務的提供者，需要和企業服務匯流排關聯上，ESB成為瓶頸：無論在效能上還是成消耗上，ESB都會導致瓶頸出現。

架構的進化，最開始我們做單體架構的時候，1990年J2EE就是把業務邏輯分為表示層、業務邏輯層、資料訪問層，之後慢慢做一些拆分，以SEB、SOAP為代表，到現在容器、雲化、敏捷、DevOps聯絡在一起。為什麼現在需要做架構？

一是網際網路的高速發展，導致傳統的企業，比如說政府、銀行要做很多的架構演進。比如說一個客戶，他原來是做保險的，保險的業務可能不是特別複雜，為什麼現在要做微服務化？因為它的使用者變了，原來是自己的業務員，現在把保險賣到網際網路上，我在小程式、淘寶各個網際網路入口都有我的使用者，使用者可以直接買，使用者的群體發生變化以後，現在給我們要求是每秒要達到幾萬，以前一秒十筆，所以帶給我們的使用者群體龐大。二是敏捷開發，這是非常強烈的剛需，我們有一個客戶他的痛點就是十點之前微軟給我搞的架構，現在要改一個東西，要六週全部上線，因為所有的點要布到，達到的價值就是持續迭代和價值特性的小批次快速交付。現在我們也進入雲化，基礎設施服務化、自動化，降低應用部署，升級和管理成本。網際網路的架構相對於傳統的很多企業，包括政府的機關銀行比現在好幾個時代，我們很多搞網際網路的同學，覺得好像沒有特別的挑戰，如果你去傳統企業看一下，感覺還活在上個世紀，你想像不到現在很多企業還這樣，很多時候雲計算給大家帶來價值，我們可以推動技術的變更和發展。

剛剛講的架構方面，我本人其實對一些現在雲計算的發展趨勢一些演進，從雲計算基礎來講三個方面；一是IaaS層，比如說應用、資料、中介軟體等等，往上是PaaS層，很多我覺得PaaS越來越成為一個重點發展的方向，最後是SaaS，比如說智慧客服等等都算是。現在更多的企業還有做一些SaaS化的應用。

越往上其實對業務性是越多的，關聯性越強，但是越到下面通用性越好，對我來說很簡單，都是標準化了，再從另外一個來看，越到下面，它其實同質化越重。

微服務只是架構的理念，容器在微服務裡面非常好地把微服務的概念落地，因為它就是一處產生多處執行，微服務其實是架構層面的，是從上而下演進，我們強調的是架構設計上面的概念，容器是資源層面的，我們原來可能計算在IaaS上，之後往PaaS延伸的，把資源進行隔離進行調動，那虛擬機器是不是也要到伺服器的級別？慢慢延伸出來容器，再講一下微服務與RPC框架，其實每個公司都有RPC框架，微服務概念沒有興起之前都已經存在了，它跟微服務有關聯性，但是沒有從本質上改變微服務的架構，其實微服務強調的是一種服務治理，Devops、敏捷，RPC/REST，我們原來做框架的就是強調協議是不是做到相互相容，還有通訊協議、同步非同步、多執行緒多程序、高效能。

講一下微服務與ServiceMesh，大家覺得ServiceMesh是不是代表將來的？ServiceMesh是在容器的基礎上，因為容器有一個特點，它還是在資源管理排程方面，對業務是無感知的，越到上越有附加值越高，ServiceMesh在容器的基礎上演化出來的技術，想去幫業務做一些更多事情的，在微服務上的管理平臺，但是這個技術有沒有問題？其實有一些問題，一是比較侷限，目前社群裡面的ServiceMesh技術，只是支援一些協議而已，對業務還是有一定的限流性。

從我們的理解來說，中臺在幹什麼？中臺這個概念也是我們的友商最先提出來的，從我們的角度來講，中臺區別於後臺，傳統上我們中臺其實並不是一個單獨組織，是區別於後臺系統和前臺系統提出來的，後臺是為了我們做功能而生，後臺只是為了功能而生，中臺是在前臺之下，後臺之上，我是解決業務問題的，為了實現功能而耦合在一起，把它變成一個平臺化的東西，這是我們對中臺的理解。舉個例子，我為什麼要做中臺這個事情？比如說電商的秒殺，大家都覺得做一個秒殺系統有很多的難度，挑戰點在哪？一是如果現在要做秒殺系統會不會被現有的網站的其他業務有衝擊，一個秒殺系統會不會拖垮整個業務系統？二是高併發的情況下對資料庫產生壓力怎麼去做管理？三是下單，秒殺就是十個單，十個東西可以秒殺，秒殺的時候怎麼去控制？四是怎麼做秒殺開始？五是下單控制，很多時候你說在頁面上控制，很多人肯定繞過你的頁面，六是下單前置檢查，七是定時上機，八是減庫存和秒殺資料怎麼一致性？但是具體到一個大的零售電商公司，它的挑戰是什麼？

秒殺只是促銷的模組一部分，還有對帳，從百貨轉到服裝，對公司來說是有難度的，後臺系統要重寫一套，原來可能是針對百貨分類做了一些處理，但是換到服裝這個品類就不行了，可能有些產品滿足不了，這個東西站在業務角度把這個東西剝離出來，很容易就做了，對大公司來說是一套系統。

其次，為什麼要做中臺？目標其實為了協助業務落地實施、改造、試錯、轉型，收益，提升組織效率，降低系統成本，圍繞業務組織，進行可複用能力的有機整合。不管是什麼中臺、業務中臺，都是圍繞著業務給他們提供可複用能力，降低成本，提升我們的效率。

這是中臺三個層次，一是雲基礎設施層，中間是技術中臺，這一塊也是我們最擅長的，三是業務中臺，面對不同行業的應用，可能有行業同學他們會主導做這個事情。這是一個傳統的零售中臺架構，閘道器技術中臺、伺服器各種業務中心，典型的一個零售業務中臺架構。

技術中臺怎麼解決問題？設計一個技術中臺，可能要服務限流，服務路由，分散式快取等等能力，這些能力怎麼組合起來，做一箇中臺應該包括兩部分，就是管控和支撐，支撐就是你的能力，對應一些後端，比如說限流伺服器這些能力就是支撐，管控就是管控一些管控平臺，我把它控制好，包括框架和執行時；所以我們把它叫做框架和執行時和管控和支撐。

技術中臺面臨的挑戰，框架、執行和支撐怎麼聯合起來？這個就像造飛機一樣，涉及到很多的技術上的挑戰，從我綜合來說兩個詞可以總結，一是化繁為簡二是深度抽象，把很複雜的東西儘量簡單化。

TSF是什麼？是一個基於微服務的提供面向業務開發過程整體技術解決方案的技術中臺，TSF微服務技術中臺核心能力，微服務框架、DeVOPS、服務化能力支撐、資料化運營、服務治理。這個中臺我們設計的架構，一個合理業務的中臺架構是什麼樣的，看看我們畫的圖：外網使用者、第三方、CLB、APL GATEWAY。目前來說現在有很多企業也面臨選擇，到底用虛擬機器還是容器，我覺得要解決業務開發過程中一系列面臨的業務問題，我們都提供統一分裝。再下面是支撐能力，種種技術統一分起來，出了問題可以快速分析。其實現在我們進行的微服務框架分了幾部分，例如微服務C可以去呼叫Spring MVC應用D，兩個不同的程式包提供一個能力的，不管你是什麼語言，什麼樣的資源，都可以。

微服務治理有幾方面，一是服務鑑權，就是服務能不能調？A能不能調動B，還有就是服務某個條件的使用者能呼叫B的某個介面，配備就可以達到這個能力。二是服務路由，路由是抽象概念，我們提供兩種方式，權重路由和標籤路由，還有多機房的路由優先。三是服務限流，我針對一些重要的介面可以設定限流能力。四是服務容量，設了四個級別。五是服務熔斷，目的是把一些故障的資訊踢掉，服務的隔離就是服務故障時候把整個服務全部遮蔽掉，配合容錯可以做一些事情。介面隔離是另外一個緯度，如果基於實際的級別統計，有時候是介面本身有問題，可以針對介面可以去做隔離，針對每個介面有不同的失敗率；我只把這個介面遮蔽返回確認就可以。六是服務降級，兩個緯度，API緯度和標籤緯度。

下面講資源管理的概念，這裡用了幾個概念，容器，另外一個是名稱空間，支援名稱空間是跨叢集的，兩個服務可以互相呼叫，部署組對於開發，如果傳統上把一個架包部署在一批上，就要選一批；另外就是應用，做程式包管理，上了一些包還有一些配置。這是我們的應用管理的，批次部署、版本管理等等。還有分散式配置，配置版本管理、實時更新、灰度釋出、多環境釋出、動態配置等等。時間有限就過了。全域性日誌，還有所謂的API治理，要引入SCK，只要加一個註解，就會自動掃描你的API，文件生成等等可以做到自動化。

還有就是微服務閘道器，這是一個很重要的入口；還有分散式事務，現在業界事務的能力，一是訊息佇列的事務，就是很多時候我把一些事務在訊息佇列級別實現，還有TCC事務，就是在框架級別它可以解決什麼問題。傳統我們提供框架級別，它把事務分為三個階段，只要三大邏輯實現就可以。FMT事務，即框架託管事務，只要你連線的是資料庫按照正常去寫你的邏輯語句，有異常的時候我會把你從前到後所有的資料庫，具體怎麼做下面可以交流。某一個段出錯我可以找出上下文給你抓出來，這是我們提供的整體能力，不包括這些，這是我們落地的專案，原開發效率提升50%，業務可進行實時響應，日常升級，業務7×24不間斷；還有中臺技術的展望，比如說部署組染色，對我們來說灰度釋出存在一個問題，我們怎麼在流量的情況下讓某些流量只流進ABC，舊的不受影響，以及全鏈路壓測，強弱依賴分析和慢查詢分析，Serverless支援，大屏運維能力。

好的技術架構都是能簡單，快速，高效的解決實際業務問題的技術架構。技術架構從我角度來說是一個工具，技術就是一個工具，工具的目的是產生收益，是讓業務獲得更大的收益，我覺得能夠快速高效簡單的解決業務問題；只要貼合業務，根據業務快速解決業務問題的架構才是好架構，今天分享這麼多，謝謝大家。

A：這就存在一個誤區，我們很多傳統寫程式碼的，不應該是讓開發用上，而是提供SCK保證你能用，而且做了高度的抽象，這些東西是不是繼續往下抽象就看你需不需要，如果只需要一個數據儲存，為了資料的讀取效率，包括現在所謂的儲存，那麼只是寫資料和讀資料，效能的問題由其他人解決。

Q：服務框架應該也看看市面上的，您能講一下哪些做得比較好？優點是哪些？

A：W是優秀的框架，這得真正承認，不是說他做的程式碼寫得多好，而是介面設計是非常優秀的，框架的層面我建議是區分兩個流派，RPC除錯起來很痛苦，其實我建議是框架的選擇，大家根據業務去選擇，比如說你的業務只要是微服務化就可以實現。