陳屹力：感謝主持人，再次感謝今天下午到場的各位嘉賓，今天下午的議題是一個標準解讀，同時也是微服務標準歷經了大概半年時間正式釋出，目前標準正在徵求意見階段，後面我們再同步跟進送審稿，最終釋出大概在9月份，待會兒我會詳細介紹。

首先說一下微服務的定義，微服務的定義公認的是ThoughWorks公司的MartinFlower的部落格描述，從他們官方的微博裡可以看到微服務架構採用一種小服務來構建應用的方法，每個服務是獨立運營，各個服務之間靠標準的RPC或者HTTP進行通訊。最重要是服務圍繞業務本身去構建，並依賴自動部署機制來獨立部署。

大家知道應用架構的整個演變過程，從單體的結構更多的是向集中架構發展到分散式架構，再到微服務架構。集中式架構就是一個War包或者其它形式的格式，釋出、執行就可以了，對於資源或者消耗是相對比較少的。二是在維護方面是統一的，哪怕是一個很小的更新也要整體打包釋出。

到微服務，整個粒度變得更小了，通過元件化去獨立開發和部署，大大有利於應用區域性的快速迭代。微服務架構的特性是隨著更新迭代的敏捷性，它的需求不易維護和難以擴充套件，其實是整個單體架構很大的一個挑戰。目前雲端計算、這種越來越龐大的體系，其實傳統架構很難去適應新的業務需求。微服務就是在當前這個容器技術非常成熟的情況下，微服務我覺得是一個面臨一個變革的趨勢。

在他們總結微服務架構的時候也同時給出了微服務的設計原則，通過服務組建化圍繞業務能力組織、產品，而非專案化模式，去中心化的治理和管理模式，智慧端點和亞管道，技術人員是更多偏向無狀態，智慧端點更多是在服務端和消費端。故障設計包括熔斷、限流這些設計。演進式設計，微服務是慢慢逐步迭代、逐步演進的過程。最後的基礎設施，儘可能的讓基礎設施IaaS層實現自動化，自動化類似於編排能力。

微服務並不是說一個徹底的創新，之前不管MVC架構還是SOA架構是一個發展階段，SOA和微服務架構粒度是不一樣的，微服務的邊界是很難定義的，沒有一個統一的邊界。在服務架構裡，SOA最大的特性是企業匯流排。相對來說它還是集中式的架構，對微服務分散式的架構，它是一個去中心化的架構。SOA按照模組服務規模相對是比較小的，到微服務拆分的粒度更小的話，逐步的應用的規模是在不斷擴充。重複式模式，業務是相對低的，獨立微服務裡面是高並舉。

微服務的優勢可以體現在幾個主要的方面，每個服務都是比較簡單單一的，只關注於某一個具體業務功能，而且微服務可以提高更高的靈活性，所謂這個靈活性哪怕你今天一是個單體架構，那麼你可以用微服務架構去實現，不斷去擴充再去迭代舊的。

微服務可以通過不同的程式語言，就是說它是跨多語言支援。微服務的開發和維護，是可以有一個獨立的團隊和組織去提供，這樣的話便於扁平化管理和快速的響應。微服務架構有利於CICD的實現。

說完微服務架構的優點，缺點也很明顯，我們怎麼樣去平衡需要在座各位去思考的問題。首先運維成本增加，粒度的減小帶來應用的示範提示是倍增的。微服務架構上的複雜性，微服務和微服務之間這種關聯越來越複雜，怎麼樣管理，這是一個很大的挑戰。

架構的複雜性，特別是跨部門、跨域的情況，分散式架構一定要考慮到很多因素，所以在架構方面也是需要多多考慮。

下面是說機制的風險，應用存在這種跨微服務的事務性處理，分散式不僅僅是微服務的問題，而且是整個分散式架構的一個問題。對於一致性的要求是怎麼樣的，是強還是弱，還是最終的一致性。

可測性比較差是微服務裡比較凸顯的，因為正常的應用開發，大家做單元測試都是很明確的，功能模組去實現單元測試，但微服務裡面這個測試起來是相對比較難的，基於微服務架構變得相對複雜。

微服務架構和技術框架這一塊，我羅列了幾種。像知名度比較高的這幾種，（見圖），這個就不太多介紹了。

對於微服務架構平臺和服務來說，我們可以考慮基於這種微服務架構，市面上提供微服務架構的廠商或者或者私有云產品有哪些。阿里雲，騰訊雲、華為雲、天眼雲都提供線上微服務平臺，國外對標的AWS和微軟。微服務平臺像靈雀等，他們都提供。

微服務架構的設計原則，在我們做這個標準的時候也考慮到了，能不能在兩個行業裡給大家一個最佳實踐，其實thoughtwork公司也給了一個設計的準則，但我們想能不能在面向國內的產業裡，或者國內使用者，因為畢竟不同行業面臨的對標不一樣。比如金融行業的監管要求，還有其它行業的，像電力、能源對安全的要求還是挺高的。我們在設計原則的時候可能是更偏於業務和管理，後面是微服務目前相對來講，相對容器類的PaaS平臺來講，國內落地還是相對少的。所以我們後面通過不斷的積累真正形成一個行業的最佳實踐，然後分享給大家。

這是微服務架構需要平衡的幾個問題，這是伸縮立方，總結的應用水平貨棧和應用微服務化和資料分割槽這三方面的權衡。後面是業務拆分需要微服務架構需要考慮的方方面面，包括人員、模組之間的切分邊界在哪裡，包括安全、運維等方面的因素都要去考慮。

首先講一下標準化的意義和必要性。微服務是一種將應用解耦的，常見的微服務框架，在不同的技術，技術沒有好壞，但在實現上或者技術路線上有很大的差異，我們大概總結去對業務儘可能的減少依賴。這兩種方式，對於使用者來講我怎麼選擇，對於產業來講還有技術生態的問題如何選擇。

國外我們也找到一個ITU的標準，國內暫時沒有。國內在我們立項的時候只有這麼一個標準，非常巧這個標準是電信在ITU立的項。

標準的起草實際上是在2017年底開始籌備，已經內部討論過很多次。2018年4月份在廈門正式起草了一個標準文稿。首先這個標準是兩個標準一起走，團體標準和行業標準是同步進行的，立項是同步進行的，但做的時候是分開的。因為CCSA有它的標準和節奏，流程相對是比較嚴格的。所以我們在4月份起草的標準文稿，先做團體標準，經過了線下六次研討，和幾次線上研討，今天形成的徵求意見稿，9月份釋出最終稿，也在那個時間前中間希望各位多給我們提意見。同時在TC1GW5標準租進行標準立項，正式通過立項申請，9月份應該是徵求意見稿。

進入到今天的主題，微服務平臺的一個架構的參考模型。標準基本上是按照邏輯關係構建的，這個圖看起來簡單，但是我們討論了不下20次，改來改去。整體分為幾塊，首先底層還是對於微服務平臺來說，底層的IT基礎設施，我們認為還是必需的，但不是重點。因為底層的IaaS是提供商層微服務平臺的重要支撐。第二層是一些公共技術服務，就是提供微服務架構的一些通用而且必要的，才放到這裡。

上面是微服務架構的核心，我們總結了微服務架構的必然能力，之外我根據不同考慮不同的場景和技術路線增加了一個增強特性，我們建議去引導整個產業，逐漸的拔高，但作為目前的階段它的要求實在是稍微有點高。最後是作為一個管理平臺要能管理你的微服務，擁有對底層資源的監控，這也是必要的。看著內容不是很多，但也是我們最終討論了很久才有這樣的結果。

下面根據架構圖分別將一下對每一層具體的要求和想法。像基礎設施是針資源管理、編排能力、部署方式有一些要求。監管，對底層物理，底層資源對上層儘可能透明，這樣對一些定位或排查錯誤的有效手段。編排能力，指標對資源的編排，儘可能是視覺化的編排方式。部署方式，私有云的場景下，能自動化的幫他部署，這樣能節省交付週期。

微服務框架的能力要求，大概有10個指標，其實11個，後面的安全服務健全放到總體安全要求裡面去了。大概介紹一下就可以了，多語言支援，這是微服務裡面強調的，語言無關性，儘可能支援兩種或兩種以上。服務通訊可以支援標準的RPC，或者SDP包括自定義的通訊協議。服務註冊，自動支援自動感知。服務發現也一樣。服務註冊，是能自動發現服務，在自助中心完成註冊。服務發現，啟動服務，自動中心能自動被感知。流量控制，在流量做一些適當的QOS的控制。負載均衡能按照權重、人群。服務契約，我們希望有一個能支援微服務統一的介面描述，符合Open1的規範。服務容錯，依賴服務出現的故障能自動半自動的在業務層面實現平滑的處理。服務熔斷對故障節點的快速轉移或者失敗轉移，停止服務，隔離能至少支援程序級的故障隔離。

公共基礎服務能力，支撐平臺不可或缺的一些服務。APM對應用之間的效能或者一些關鍵指標起到量化的作用，這樣方便運維層面管理。服務閘道器，大家知道微服務裡面有一個很重要的是服務閘道器，基於規則、路徑、協議、轉發等實現服務自動發現、服務呼叫。

增強特性是兩個指標，一是故障輸入，二是分散式事務，分散式事務是根據使用者的需求或者要求去實現基於分散式架構的分散式事務的比如強一致性、弱一致性，和最終一致性。

故障測試是在上線之前做的故障測試的一個手段，便於你處理一些應急或不可預知的一些錯誤。

管理平臺，這幾個就不介紹了。包括流水線，流水線就是整個對於微服務來講，需要具備的一些管理能力。

效能要求，其實我們在標準裡面是不便於提出來對效能方面的一些要求，但我們在討論這些事情的時候，是說不同的通訊協議、技術路線和優化方案，對於它的效能是有很大影響。那麼我們是不是可以提出來幾個指標供行業裡面去參考？比如說你去固定統一的資源配置去驗證它的效能，這是我們想強調的，並不是說我們要要求什麼樣。後面我們逐步的，比如在行業裡面有一個評估的手段來了解整個行業的平均水平怎麼樣的，就可以列出什麼樣的情況下，它的效能要到達一個合理的區間。

安全能力要求，一是通過TRS或者證書的方式去鑑定它的身份。二是它有沒有許可權去訪問，進行服務呼叫。

配置加密，對於配置管理，難免會遇到一些比較敏感的資料，通過手段去保證資料的私密性。

下面說一下軟體產品標準化和一些成果。我目前主要工作是在軟體產品，也就是私有云或者面向雲端計算通用的關鍵技術的解決方案和產品一類的標準。2016年7月做了一個開源解決方案，2017年6月份做了一個容器的，到今年做了一個微服務平臺，目前是三個標準。

我們標準在國際化上，2018年3月份跟CNCF做了一個國際對標，也就是深度的合作，雙方認可各自的標準或規範。我們知道CNCF是有一個一致性認證的，我們做了一個雙認的，最後起名TCCK，主要是針對容器的。本來之前是三個，騰訊雲、網易雲和中興，今年增加了兩個，博雲和靈雀雲。

我們在微服務的正式稿釋出之前徵求微服務的評估標準，行業標準也在同步跟進，下一步著手微服務平臺的評估工作，進一步深化微服務在行業中的一些應用。

第三個，也是跟我的工作相關，持續跟進關鍵技術的標準化進展，可能下半年會同時啟動共有云行業的標準制定。

最後，我們在國際上的合作還是更加深入一點，就是跟國際的組織或者開源社群加強合作。

最後感謝這個標準的核心編寫單位，（見圖），信通院牽頭，華為、騰訊、博雲、希雲、電信、H3C等等。我們今天請來了幾位核心編寫人員，今天在場的有4位，同時感謝名單裡面的核心編制人員。