為什麼選擇微服務架構? 微服務架構的10個核心優勢 總結
文章目錄
- 為什麼選擇微服務架構? 微服務架構的10個核心優勢 總結
- 1. 什麼是微服務？
- 2. 微服務架構有哪些特征？
- 1）通過服務實作元件化
- 2） 按業務能力來劃分服務與組織團隊
- 3）服務即産品
- 4）智能終端與啞管道
- 5）去中心統一化
- 6）基礎設施自動化
- 7） Design for failure
- 8） 進化設計
- 3. 為什麼要使用微服務架構？
- 開發單體式應用
- 單體式應用的不足
- 那麼如何應對上述的問題呢？
- 解決方案：微處理架構——處理複雜事務
- 4. 微服務架構跟SOA有什麼不一樣？
- 5. 微服務架構的好處有哪些？
- 6. 微服務架構的不足有哪些？
- 7. 微服務架構的組織結構是怎樣的？
- 8. 為什麼微服務是産品而非項目視角？
- 9. 微服務跨越不同程序建構通信結構的方式是怎樣的？
- -- Ian Robinson
- 10.實施微服務架構，應該從哪些次元來考量？
- 模組化
- 協作
- 測試
- 部署
- 監控
- 總結：
- 結語
1. 什麼是微服務？
微服務架構我們沒有一個明确的定義，但簡單來說微服務架構是： 采用一組服務的方式來建構一個應用，服務獨立部署在不同的程序中，不同服務通過一些輕量級互動機制來通信，例如 RPC、HTTP 等，服務可獨立擴充伸縮，每個服務定義了明确的邊界，不同的服務甚至可以采用不同的程式設計語言來實作，由獨立的團隊來維護。
2. 微服務架構有哪些特征？
1）通過服務實作元件化
傳統實作元件的方式是通過庫（library），傳統元件是和應用一起運作在程序中，元件的局部變化意味着整個應用的重新部署。 通過服務來實作元件，意味着将應用拆散為一系列的服務運作在不同的程序中，那麼單一服務的局部變化隻需重新部署對應的服務程序。 另外将服務作為元件可以更明确的定義出元件的邊界。
2） 按業務能力來劃分服務與組織團隊
康威定律（Conway’s law）指出：
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
任何設計系統的組織，最終産生的設計等同于組織之内、之間的溝通結構。
傳統開發方式中，我們将工程師按技能專長分層為前端層、中間層、資料層，前端對應的角色為UI、頁面建構師等，中間層對應的角色為服務端業務開發工程師，資料層對應着DBA等角色。 事實上傳統應用設計架構的分層結構正反應了不同角色的溝通結構。 而微服務架構的開發模式不同于傳統方式，它将應用按業務能力來劃分為不同的服務，每個服務都要求在對應業務領域的全棧（從前端到後端）軟體實作，從界面到資料存儲到外部溝通協作等等。 是以團隊的組織是跨功能的，包含實作業務所需的全面的技能。 近年興起的全棧工程師正是因為架構和開發模式的轉變而出現，當然具備全棧的工程師其實很少，但将不同領域的工程師組織為一個全棧的團隊就容易的多。
3）服務即産品
傳統的應用開發都是基于項目模式的，開發團隊根據一堆功能清單開發出一個軟體應用并傳遞給客戶後，該軟體應用就進入維護模式，由另一個維護團隊負責，開發團隊的職責結束。 而微服務架構的倡導者提議避免采用這種項目模式，更傾向于讓開發團隊負責整個産品的全部生命周期。Amazon 對此提出了一個觀點：
You buidl it, you run it.
開發團隊對軟體在生産環境的運作負全部責任，讓服務的開發者與服務的使用者（客戶）形成每天的交流回報，來自直接用戶端的回報有助于開發者提升服務的品質。
4）智能終端與啞管道
微服務架構抛棄了 ESB 過度複雜的業務規則編排、消息路由等。 服務作為智能終端，所有的業務智能邏輯在服務内部處理，而服務間的通信盡可能的輕量化，不添加任何額外的業務規則。
5）去中心統一化
傳統應用中傾向采用統一的技術平台或産品來解決所有問題。 不是每個問題都是釘子，也不是每個解決方案都是一個錘子。 問題有其具體性，解決方案也應有其針對性。 用最适合的技術方案去解決具體的問題，在大一統的傳統應用中其實很難做到，而微服務的架構意味着，你可以針對不同的業務服務特征選擇不同的技術平台或産品，有針對性的解決具體的業務問題。
6）基礎設施自動化
單一程序的傳統應用被拆分為一系列的多程序服務後，意味着開發、調試、測試、內建、監控和釋出的複雜度都會相應增大。 必須要有合适的自動化基礎設施來支援微服務架構模式，否則開發、運維成本将大大增加。
7） Design for failure
正因為将服務獨立在不同的程序中後，引入了額外的失敗因素。 任何時刻對服務的調用都可能因為服務方不可用導緻失敗，這就要求服務的消費方需要優雅的處理此類錯誤。 這其實是相對傳統應用開發方式的一個缺點，不過随着一些開源服務化架構的出現，對業務開發人員而言适當的屏蔽了類似的錯誤處理，不過開發人員依然需要知道對服務的調用是完全不同于程序内的方法或函數調用的。
8） 進化設計
一旦采用了微服務架構模式，那麼在服務需要變更時我們要特别小心，服務提供者的變更可能引發服務消費者的相容性破壞，時刻謹記保持服務契約（接口）的相容性。 對于解耦服務消費方和服務提供方，伯斯塔爾法則（Postel’s law）特别适用：
Be conservative in what you send, be liberal in what you accept.
發送時要保守，接收時要開放。
按照伯斯塔爾法則的思想來設計實作服務調用時，發送的資料要更保守，意味着最小化的傳送必要的資訊，接收時更開放意味着要最大限度的容忍資訊的相容性。 多餘的資訊不認識可以忽略，而不應該拒絕或抛出錯誤。
3. 為什麼要使用微服務架構？
開發單體式應用
假設你正準備開發一款與Uber和Hailo競争的計程車排程軟體，經過初步會議和需求分析，你可能會手動或者使用基于Rails、Spring Boot、Play或者Maven的生成器開始這個新項目，它的六邊形架構是子產品化的應用核心是業務邏輯，由定義服務、域對象和事件的子產品完成。圍繞着核心的是與外界打交道的擴充卡。擴充卡包括資料庫通路元件、生産和處理消息的消息元件，以及提供API或者UI通路支援的web子產品等。
盡管也是子產品化邏輯，但是最終它還是會打包并部署為單體式應用。具體的格式依賴于應用語言和架構。例如，許多Java應用會被打包為WAR格式，部署在Tomcat或者Jetty上，而另外一些Java應用會被打包成自包含的JAR格式，同樣，Rails和Node.js會被打包成層級目錄。
這種應用開發風格很常見，因為IDE和其它工具都擅長開發一個簡單應用，這類應用也很易于調試，隻需要簡單運作此應用，用Selenium連結UI就可以完成端到端測試。單體式應用也易于部署，隻需要把打包應用拷貝到伺服器端，通過在負載均衡器後端運作多個拷貝就可以輕松實作應用擴充。在早期這類應用運作的很好。
單體式應用的不足
不幸的是，這種簡單方法卻有很大的局限性。一個簡單的應用會随着時間推移逐漸變大。在每次的sprint中，開發團隊都會面對新“故事”，然後開發許多新代碼。幾年後，這個小而簡單的應用會變成了一個巨大的怪物。
一旦你的應用變成一個又大又複雜的怪物，那開發團隊肯定很痛苦。靈活開發和部署舉步維艱，其中最主要問題就是這個應用太複雜，以至于任何單個開發者都不可能搞懂它。是以，修正bug和正确的添加新功能變的非常困難，并且很耗時。另外，團隊士氣也會走下坡路。如果代碼難于了解，就不可能被正确的修改。最終會走向巨大的、不可了解的泥潭。
單體式應用也會降低開發速度。應用越大，啟動時間會越長。比如，最近的一個調查表明，有時候應用的啟動時間居然超過了12分鐘。我還聽說某些應用需要40分鐘啟動時間。如果開發者需要經常重新開機應用，那麼大部分時間就要在等待中渡過，生産效率受到極大影響。
另外，複雜而巨大的單體式應用也不利于持續性開發。今天，SaaS應用常态就是每天會改變很多次，而這對于單體式應用模式非常困難。另外，這種變化帶來的影響并沒有很好的被了解，是以不得不做很多手工測試。那麼接下來，持續部署也會很艱難。
單體式應用在不同子產品發生資源沖突時，擴充将會非常困難。比如，一個子產品完成一個CPU敏感邏輯，應該部署在AWS EC2 Compute Optimized instances，而另外一個記憶體資料庫子產品更合适于EC2 Memory-optimized instances。然而，由于這些子產品部署在一起，是以不得不在硬體選擇上做一個妥協。
單體式應用另外一個問題是可靠性。因為所有子產品都運作在一個程序中，任何一個子產品中的一個bug，比如記憶體洩露，将會有可能弄垮整個程序。除此之外，因為所有應用執行個體都是唯一的，這個bug将會影響到整個應用的可靠性。
最後，單體式應用使得采用新架構和語言非常困難。比如，設想你有兩百萬行采用XYZ架構寫的代碼。如果想改成ABC架構，無論是時間還是成本都是非常昂貴的，即使ABC架構更好。是以，這是一個無法逾越的鴻溝。你不得不在最初選擇面前低頭。
那麼如何應對上述的問題呢？
解決方案：微處理架構——處理複雜事務
許多公司，比如Amazon、eBay和NetFlix，通過采用微處理結構模式解決了上述問題。其思路不是開發一個巨大的單體式的應用，而是将應用分解為小的、互相連接配接的微服務。
一個微服務一般完成某個特定的功能，比如下單管理、客戶管理等等。每一個微服務都是微型六角形應用，都有自己的業務邏輯和擴充卡。一些微服務還會釋出API給其它微服務和應用用戶端使用。其它微服務完成一個Web UI，運作時，每一個執行個體可能是一個雲VM或者是Docker容器。
比如，一個系統可能分解，讓每一個應用功能區都使用微服務完成，另外，Web應用會被拆分成一系列簡單的Web應用（比如一個對乘客，一個對計程車駕駛員）。這樣的拆分對于不同使用者、裝置和特殊應用場景部署都更容易。
每一個背景服務開放一個REST API，許多服務本身也采用了其它服務提供的API。比如，駕駛員管理使用了告知駕駛員一個潛在需求的通知服務。UI服務激活其它服務來更新Web頁面。所有服務都是采用異步的，基于消息的通訊。微服務内部機制将會在後續系列中讨論。
一些REST API也對乘客和駕駛員采用的移動應用開放。這些應用并不直接通路背景服務，而是通過API Gateway來傳遞中間消息。API Gateway負責負載均衡、緩存、通路控制、API 計費監控等等任務，可以通過NGINX友善實作，後續文章将會介紹到API Gateway。
微服務架構模式在上圖中對應于代表可擴充Scale Cube的Y軸，這是一個在《The Art of Scalability》書中描述過的三維擴充模型。另外兩個可擴充軸，X軸由負載均衡器後端運作的多個應用副本組成，Z軸是将需求路由到相關服務。
應用基本可以用以上三個次元來表示，Y軸代表将應用分解為微服務。運作時，X軸代表運作多個隐藏在負載均衡器之後的執行個體，提供吞吐能力。一些應用可能還是用Z軸将服務分區。下面的圖示範行程管理服務如何部署在運作于AWS EC2上的Docker上。
運作時，行程管理服務由多個服務執行個體構成。每一個服務執行個體都是一個Docker容器。為了保證高可用，這些容器一般都運作在多個雲VM上。服務執行個體前是一層諸如NGINX的負載均衡器，他們負責在各個執行個體間分發請求。負載均衡器也同時處理其它請求，例如緩存、權限控制、API統計和監控。
這種微服務架構模式深刻影響了應用和資料庫之間的關系，不像傳統多個服務共享一個資料庫，微服務架構每個服務都有自己的資料庫。另外，這種思路也影響到了企業級資料模式。同時，這種模式意味着多份資料，但是，如果你想獲得微服務帶來的好處，每個服務獨有一個資料庫是必須的，因為這種架構需要這種松耦合。
每種服務都有自己的資料庫，另外，每種服務可以用更适合自己的資料庫類型，也被稱作多語言一緻性架構。比如，駕駛員管理（發現哪個駕駛員更靠近乘客），必須使用支援地理資訊查詢的資料庫。
表面上看來，微服務架構模式有點像SOA，他們都由多個服務構成。但是，可以從另外一個角度看此問題，微服務架構模式是一個不包含Web服務（WS-）和ESB服務的SOA。微服務應用樂于采用簡單輕量級協定，比如REST，而不是WS-，在微服務内部避免使用ESB以及ESB類似功能。微服務架構模式也拒絕使用canonical schema等SOA概念。
4. 微服務架構跟SOA有什麼不一樣？
SOA與微服務應用了很多相同的原則，隻是在組織中的應用層次不同。SOA專注于對“大型服務”進行編排操作，但這些大型服務也可以通過對一系列微服務進行組合而實作。服務的大小并不是一種定義微服務的好方法。
表面上看來，微服務架構模式有點像SOA，他們都由多個服務構成。從另外一個角度看此，微服務架構模式是一個不包含Web服務（WS-）和ESB服務的SOA。
SOA的提出是在企業計算領域，就是要将緊耦合的系統，劃分為面向業務的，粗粒度，松耦合，無狀态的服務。服務釋出出來供其他服務調用，一組互相依賴的服務就構成了SOA架構下的系統。
基于這些基礎的服務，可以将業務過程用類似BPEL流程的方式編排起來，而BPEL反映的是業務處理的過程，這些過程對于業務人員更為直覺，調整也比hardcode的代碼更容易。當然企業還需要對服務治理，比如服務注冊庫，監控管理等。
我們知道企業計算領域，如果不是交易系統的話，并發量都不是很大的，是以大多數情況下，一台伺服器就容納将許許多多的服務，這些服務采用統一的基礎設施，可能都運作在一個應用伺服器的程序中。雖然說是面向服務了，但還是單一的系統。
而微服務架構大體是從網際網路企業興起的，由于大規模使用者，對分布式系統的要求很高，如果像企業計算那樣的系統，伸縮就需要多個容納續續多多的服務的系統執行個體，前面通過負載均衡使得多個系統成為一個叢集。
但這是很不友善的，網際網路企業疊代的周期很短，一周可能釋出一個版本，甚至可能每天一個版本，而不同的子系統的釋出周期是不一樣的。
而且，不同的子系統也不像原來企業計算那樣采用集中式的存儲，使用昂貴的Oracle存儲整個系統的資料，二是使用MongoDB，HBase，Cassandra等NOSQL資料庫和Redis，memcache等分布式緩存。
那麼就傾向采用以子系統為分割，不同的子系統采用自己的架構，那麼各個服務運作自己的Web容器中，當需要增加計算能力的時候，隻需要增加這個子系統或服務的執行個體就好了，當更新的時候，可以不影響别的子系統。這種組織方式大體上就被稱作微服務架構。
微服務與SOA相比，更強調分布式系統的特性，比如橫向伸縮性，服務發現，負載均衡，故障轉移，高可用。網際網路開發對服務治理提出了更多的要求，比如多版本，比如灰階更新，比如服務降級，比如分布式跟蹤，這些都是在SOA實踐中重視不夠的。
5. 微服務架構的好處有哪些？
微服務架構模式有很多好處。
首先，通過分解巨大單體式應用為多個服務方法解決了複雜性問題。在功能不變的情況下，應用被分解為多個可管理的分支或服務。每個服務都有一個用RPC-或者消息驅動API定義清楚的邊界。微服務架構模式給采用單體式編碼方式很難實作的功能提供了子產品化的解決方案，由此，單個服務很容易開發、了解和維護。
第二，這種架構使得每個服務都可以有專門開發團隊來開發。開發者可以自由選擇開發技術，提供API服務。當然，許多公司試圖避免混亂，隻提供某些技術選擇。然後，這種自由意味着開發者不需要被迫使用某項目開始時采用的過時技術，他們可以選擇現在的技術。甚至于，因為服務都是相對簡單，即使用現在技術重寫以前代碼也不是很困難的事情。
第三，微服務架構模式是每個微服務獨立的部署。開發者不再需要協調其它服務部署對本服務的影響。這種改變可以加快部署速度。UI團隊可以采用AB測試，快速的部署變化。微服務架構模式使得持續化部署成為可能。
最後，微服務架構模式使得每個服務獨立擴充。你可以根據每個服務的規模來部署滿足需求的規模。甚至于，你可以使用更适合于服務資源需求的硬體。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務，而在EC2 memory-optimized instances上部署記憶體資料庫。
6. 微服務架構的不足有哪些？
像任何其它科技一樣，微服務架構也有不足。其中一個跟他的名字類似，『微服務』強調了服務大小，實際上，有一些開發者鼓吹建立稍微大一些的，10-100 LOC服務組。盡管小服務更樂于被采用，但是不要忘了這隻是終端的選擇而不是最終的目的。微服務的目的是有效的拆分應用，實作靈活開發和部署。
另外一個主要的不足是，微服務應用是分布式系統，由此會帶來固有的複雜性。開發者需要在RPC或者消息傳遞之間選擇并完成程序間通訊機制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當然這并不是什麼難事，但相對于單體式應用中通過語言層級的方法或者程序調用，微服務下這種技術顯得更複雜一些。
另外一個關于微服務的挑戰來自于分區的資料庫架構。商業交易中同時給多個業務分主體更新消息很普遍。這種交易對于單體式應用來說很容易，因為隻有一個資料庫。在微服務架構應用中，需要更新不同服務所使用的不同的資料庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴充性的NoSQL資料庫和消息傳遞中間件并不支援這一需求。最終你不得不使用一個最終一緻性的方法，進而對開發者提出了更高的要求和挑戰。
測試一個基于微服務架構的應用也是很複雜的任務。比如，采用流行的Spring Boot架構，對一個單體式web應用，測試它的REST API，是很容易的事情。反過來，同樣的服務測試需要啟動和它有關的所有服務（至少需要這些服務的stubs）。再重申一次，不能低估了采用微服務架構帶來的複雜性。
另外一個挑戰在于，微服務架構模式應用的改變将會波及多個服務。比如，假設你在完成一個案例，需要修改服務A、B、C，而A依賴B，B依賴C。在單體式應用中，你隻需要改變相關子產品，整合變化，部署就好了。對比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。比如，你需要更新服務C，然後是B，最後才是A，幸運的是，許多改變一般隻影響一個服務，而需要協調多服務的改變很少。
部署一個微服務應用也很複雜，一個分布式應用隻需要簡單在複雜均衡器後面部署各自的伺服器就好了。每個應用執行個體是需要配置諸如資料庫和消息中間件等基礎服務。相對比，一個微服務應用一般由大批服務構成。例如，根據Adrian Cockcroft，Hailo有160個不同服務構成，NetFlix有大約600個服務。每個服務都有多個執行個體。這就造成許多需要配置、部署、擴充和監控的部分，除此之外，你還需要完成一個服務發現機制，以用來發現與它通訊服務的位址（包括伺服器位址和端口）。傳統的解決問題辦法不能用于解決這麼複雜的問題。接續而來，成功部署一個微服務應用需要開發者有足夠的控制部署方法，并高度自動化。
一種自動化方法是使用PaaS服務，例如Cloud Foundry。PaaS給開發者提供一個部署和管理微服務的簡單方法，它把所有這些問題都打包内置解決了。同時，配置PaaS的系統和網絡專家可以采用最佳實踐和政策來簡化這些問題。另外一個自動部署微服務應用的方法是開發對于你來說最基礎的PaaS系統。一個典型的開始點是使用一個叢集化方案，比如配合Docker使用Mesos或者Kubernetes。
7. 微服務架構的組織結構是怎樣的？
“微”服務并不一定微。服務的具體規模可謂多種多樣。其中規模最大的成果源自Amazon公司旗下的“兩塊披薩”團隊（即整個團隊隻需兩塊披薩即可填飽肚子），這意味着其總人數在十位左右。而規模較小的團隊則由六人組成，負責支援六項服務。
采取此類組織方式的企業執行個體，其各職能團隊共同負責建構并營運每款産品，而每款産品則被拆分為一系列獨立的服務——且各服務間通過一套消息收發總線實作通信。
大型整體應用程式亦可以始終圍繞業務功能實際子產品化，由大型團隊建構的單一整體應用程式根據自身業務線進行設計與劃分。然而在這類情況下，最大的問題在于整體應用程式在組織當中需要考慮太多背景資訊。如果其整體範疇當中包含太多子產品邊界，那麼團隊中的單一成員将很難通過短期記憶對其進行管理。
這種子產品化業務線的維護工作還要求相關人員具備極高的專業技能水準。相比之下，服務元件能夠令拆分方式更為明确，進而大大簡化團隊邊界的設定與認知。
8. 為什麼微服務是産品而非項目視角？
大部分應用程式開發工作都會遵循項目模式：其目标在于傳遞軟體方案中的特定部分，并擁有直覺的完成名額。在軟體開發工作完成後，其會被傳遞至運維部門，這時負責建構該軟體的團隊也将即刻解散。
微服務的支援者們則認為這種模式并不可取——他們的主張是相關團隊應該伴随産品走過整個生命周期。這方面最典型的例子應該是Amazon公司提出的“誰建構，誰運作”原則，其中開發團隊需要對生産環境下的軟體成果承擔全部責任。這就要求開發人員在日常工作中全程關注其軟體的生産運作情況，同時掌握來自使用者的回報意見，意味着他們需要在一定程度上為使用者提供技術支援服務。
産品的定位應始終與業務功能相協調。相較于以往将軟體視為一整套已經完成的功能集的心态，微服務架構要求我們全程與之保持關聯，并思考該軟體能夠如何協助使用者加強業務功能。
當然，我們完全可以将同樣的思路引入整體應用程式當中，不過大量小型服務集合能夠顯著簡化服務開發人員與及使用者之間的個人聯系。
9. 微服務跨越不同程序建構通信結構的方式是怎樣的？
在跨越不同程序建構通信結構時，我們發現很多産品及方案會直接把智能化機制塞進通信機制本體當中。這方面的典型執行個體就是企業服務總線（簡稱ESB），ESB産品當中通常包含複雜度極高的消息跌幅、編排、轉換以及業務規則應用等機制。
微服務社群則傾向于使用另一種實作方式：智能化端點與傻瓜式流程。采用微服務架構的應用程式旨在盡可能實作解耦化與關聯性——它們各自擁有自己的域邏輯，而且在經典Unix場景下的運作方式更像是過濾器機制——接收請求、應用合适的邏輯并生成響應。這一切都通過簡單的REST類協定實作編排，而非經由WS-Choreography或者BPEL等複雜協定以及中央編排工具實作。
目前最常用的兩類協定為配合源API的HTTP請求-響應與輕量化消息收發協定。對于前者，最簡練而準确的說明是：
立足于Web，而非居于Web背後。
– Ian Robinson
微服務團隊采用的正是網際網路（在很大程度上亦包括Unix在内）所遵循的原則與協定。一般來講，其使用的資源能夠為開發人員或者運維人員輕松實作緩存處理。
第二類作法則是立足于輕量化消息總線實作消息收發。這類基礎設施選項通常具備傻瓜式特性（這種傻瓜特性展現在實作操作上，即隻需比對消息路由機制，再無其它）——以RabbitMQ或者ZeroMQ為代表的簡單實作方案僅僅需要提供一套可靠的異步結構，而服務的全部智能化元素仍然存在于端點當中并負責消息的生成與消費。
在整體應用程式當中，各元件在程序内執行并通過方法調用或者函數調用的方式實作彼此通信。将整體應用程式轉化為微服務形式的最大難題在于改變這種通信模式。由記憶體内方法調用指向PC通信機制的簡單轉換往往無法良好起效。相反，大家需要利用粗粒度方式取代原本的細粒度通信機制。
10.實施微服務架構，應該從哪些次元來考量？
模組化
服務圍繞業務能力模組化，服務應該清晰地反應業務能力。
協作
采用微服務架構模式後，開發和運作的協作模式都會發生變化。
按微服務的組織方式，不同人或小團隊負責一個或一組微服務，服務之間可能存在互相調用關系，是以在服務之間也完全采用了像面向外部開放的契約化開發模式。
每一個服務都提供了一份契約文檔，釋出到公開的内部 wiki，友善服務幹系人可自由擷取檢視。契約文檔要求至少對服務的幾個基本方面作出說明，如下：
－API，具體接口的 API 接入技術說明。
－ 能力，服務能力的描述。
－ 契約，提供這些能力所約定的一些限制條件說明。
－ 版本，支援的最新和曆史的版本說明。
使用契約文檔來減少多餘且可能反複重複的口頭溝通，降低協作成本。
采用微服務後一個業務功能的調用會涉及多個服務間的協同工作，由于服務間都是跨進城的調用通信，一個業務功能的完成涉及的服務調用鍊條可能較長，這就涉及到服務間需遵循一些規則來確定協作的可靠性和可用性。我們采用的原則是：長鍊條的内部服務之間的調用異步化。若一個調用鍊條中的個别服務變慢或阻塞可能導緻整個鍊條産生雪崩效應，采用異步化來規避調用阻塞等待導緻的雪崩情形。
測試
而微服務的測試，服務開發和營運人員專注于做好服務實作層面的單元測試和服務契約層面的接口測試。而面向業務功能的端到端測試，更多是依賴自動化腳本完成。而為了維護好這些自動化測試腳本，也需要保持服務接口和契約的相容性和穩定性，這些自動化測試腳本也屬于服務的消費方之一。
部署
借助于虛拟化或容器等隔離技術，每個服務感覺都是獨享資源，不必考慮額外的資源使用沖突。
監控
大量松耦合的微服務通過互相協作來完成業務功能的流程處理，在這樣一個複雜的生産環境中，出現異常或錯誤是很難迅速定位的。這就需要一套成體系的監控基礎設施，在我們的實踐中借助了公司統一的監控基礎設施，對監控進行了分層，頂層的監控站在使用者視角，底層的監控站在系統視角，形成更完善的回報鍊路。