7月2日，2019/35888.html">2019可信云大會在北京國際會議中心隆重開幕。2019/35888.html">2019可信云大會以“智能云網邊，可信創未來”為主題，由中國信息通信研究院主辦。

下午13:30大會特設的智能云論壇活動正式開始，微軟（中國）有限公司微軟全球技術黑帶專家馬平做了《AKS支撐微服務架構&Azure DevOps加速微服務迭代開發》的精彩演講。

微軟（中國）有限公司微軟全球技術黑帶專家馬平

大家下午好！我的演講題目分兩部分，一是AKS支撐微服務架構，另外一個是DevOps加速微服務迭代開發。

我叫馬平，是微軟全球技術黑帶，微軟全球技術黑帶是一個部門名稱，在這個部門中基本是一些技術專家，我負責的是容器、中間件、微服務、Serverless和DevOps等。

目前微軟在云上的認證有兩個專家級別的證書，這兩個證書強烈向大家推薦考一下。

我們在談論一個問題時首先要知道談論這個問題的范圍。（圖）7月2號、7月3號所有的議題內容基本在這張圖上都能找到。IT發展到今天分為三大板塊：

1.IT的基礎架構，就是網絡、計算、存儲；

2.數據架構，數據架構不要理解成為光是數據庫，包括非數據庫，大數據、人工智能，因為人工智能如果沒有數據、沒有大數據的話，是玩不轉的；

3.與微服務相關的就是應用架構。應用架構層發展到今天有各種各樣的，如兩層、三層、SOA等等，今天叫微服務，微服務架構比較有特點，它雖然是應用層的架構，但對底層架構、對數據層架構都有要求，并不是只在應用層考慮就可以。所以大家討論微服務架構時一定要明確，微服務架構雖然在應用層架構，實際上對底層基礎架構、數據架構都有要求，甚至對于持續集成、持續發布、服務發現等等也都有要求。這是我們在談論一個IT問題時需要明確這個問題屬于哪個范圍。

一、微服務架構基本概念

一般我講東西的時候不愿意講概念，特別是講太底層的概念，習慣的是首先這個東西為什么會有，把這個東西想清楚了，這門技術就會有自己的獨立判斷，它有沒有發展前景，是不是基于新的技術架構應該采用的微服務架構。

為什么要采用它？當出現什么樣的問題時會考慮微服務？其實有一點大家可以很明確，如剛剛說的三層架構，底層基礎架構，有一天忽然發現不管底層基礎架構怎么變，都難以承受達到一定程度的高并發的用戶請求數的響應。

早期我做中間件，做一個底層集群，多少節點支撐多少用戶量級的并發數？我知道最高是16個節點。但這個并發數也是有限的，再增加怎么辦？這就是問題。應用高并發存在性能瓶頸這一項，如果應用存在類似問題，基本上要考慮微服務。業務復雜性、團隊規模日益擴大、單體應用維護升級部署難度加大，這些在我看來不是必然因素，因為這些因素可以通過管理去解決，可以通過設計去解決，但是高并發是一個硬的，不能支撐就是不能支撐，100臺機器組成一個集群不現實，無法維護，這是為什么要使用微服務。

微服務架構：What？

微服務架構是隨著云計算的發展應運而生的一種微軟設計風格，與之對立的是傳統的單體架構。

除了技術視角，給大家一個業務視角，單一職責原則，一個微服務做一件事情，不要一個微服務做很多事情。然后再說這個技術實現特點是什么？一個微服務就是一個獨立的進程。是按照業務而不是技術的邊界來確定一個微服務。從業務視角，每一個微服務是做一件事情，而且這一件事情是有一個明確的業務邊界，所以能做到這一點，就知道微服務大概是什么樣的架構。

從技術人員角度來講，因為每一個微服務是一個獨立的進程，可以想像將來的應用是分布式應用，不是一個應用。

微服務架構：Why？

比如迭代效率慢，提升迭代效率是可以做到的，因為每個服務做成微服務以后，微服務是獨立開發部署，不需要依賴于其他的微服務。

彈性擴展，高可用，怎么做到？每一個微服務都可以做到自己的彈性擴展，想擴展到多少個就擴展到多少個，假設底層硬件是足夠支撐情況下。

容錯，不可能某一個微服務down掉就會導致整個應用全部崩潰，這種情況不允許出現，但這種情況在單體應用當中經常會出現。單體應用當中某一個組件占用內存過多，導致整個應用無法接受處理客戶請求，這有可能出現，但在微服務里這是不會出現的。