乍一看微服務似乎很容易構建，但是要真正構建微服務，要完成的工作可比在容器裡執行一些**，並在這些**間使用http請求進行通訊，要多得多。在開發新的微服務之前——必須得在新服務部署到生產環境之前——你需要回答下面這10個重要的問題。
當考慮到測試時， 微服務 有一些優勢和劣勢。一方面，定義良好的一小段功能的小型服務的單元測試，要比測試整個大型應用程式容易得多。另一方面，要驗證由很多微服務組成的整個應用程式的質量，則必然會顯著加大測試的複雜度：無法執行單個命令來測試乙個程序裡的**，大量整合的互相依賴的元件必須首先執行起來，才能驗證其健康狀況，並且需要在測試過程中一直保持其執行。
新的微服務是否既會進行隔離測試（使用單元測試或模擬依賴），也會連線到一些生產環境裡實際會連線的服務上，在更貼近實際使用情況的「整合」或者「過渡」環境裡進行測試？測試是否會合併效能驗證和錯誤模式？是否所有測試都會自動化，或者需要人為幹**試的執行以及測試結果的檢視？要讓微服務可以簡單，快速，並且自動化地進行測試，這鼓勵開發人員維護測試，並且避免「 破窗 」問題。
一旦新的微服務部署到生產環境裡，如何才能影響其內部行為？這裡包括基礎架構的改動（比如，在資源池裡改變最小程序數），以及一些應用程式級別的改動（比如，通過觸發 特性標誌 來啟動新特性）。對於這所有的改動，要重點注意讓這些改動生效是否需要重啟服務。
除非系統的其他元件的確需要使用某個服務，才有必要構建它，因此理解它們會如何使用該服務至關重要。
需要清晰定義這個新的微服務所能夠提供的響應延遲，呼叫該服務的元件必須知道這些指標。這樣，當沒有達到這些指標時，系統的其他部分才能夠決定發出超時訊號，中斷當前操作，或者轉到服務的另乙個例項上。
除非在乙個要求高度安全的環境裡，大部分部署在防火牆後的微服務不需要過多操心服務內的安全性。在微服務之間新增大量的安全檢查會帶來巨大的操作複雜度，並且使得生產環境問題更難除錯和修復。即使為服務內通訊使用http之上的https都會因為要求維護，部署以及保護一些正確簽名的證書，而帶來大量維護上的額外開銷。
通常的方案是讓流量在微服務間暢行無阻，同時使用應用程式級別的授權和認證，這樣來保證應用程式級別的安全。
因此，系統裡的其他元件應該能夠給微服務傳送請求，但是可能仍然需要同時傳遞一些認證資料，這些資料代表實際被批准的該請求最初的外部使用者。這些資料永遠不能是明文密碼資料，可以使用類似 jwt ， oauth ， saml 和 auth0 這樣的技術。不管使用哪種方案，都需要清晰記錄所用技術，最好包含在客戶端庫或者示例**裡，從而讓其他開發人員能夠輕鬆使用這個新的微服務。
當新的微服務啟動後，系統裡的其他元件如何發現它？發現服務的流程越簡單，可能的複雜度就越小，但是之後面臨的問題就會越多。比如，最簡單的方法（當然也很容易出錯）就是在其他依賴於該服務的元件**或者配置裡硬編碼微服務的位址。這樣確實能夠工作，直到服務位址發生變動，或者直到在其他域裡啟動了該服務的多個例項。這顯然不是推薦的方式。
使用間接技術，比如dns名稱，能夠一定程度上更好地隱藏微服務的位址，但是這樣的方案也有自身的缺陷：找到乙個合適的ttl值，強制重做名稱解析，保證dns快取行為一致，等等。從設計上看，dns並沒有考慮服務的可用性，這會使得應用程式的元件將請求傳送到乙個無人偵聽的ip位址，會很浪費時間，並且因為嘗試找到能夠工作的例項而干擾到實際的運營。這也會讓開發人員的體驗非常糟糕，因為使用dns作為路由機制通常會導致開發人員需要頻繁修改其/etc/hosts檔案。
最複雜的方案裡，高可用的資料庫和資料同步服務（比如zookeeper）可能會用作當前可用並且工作良好的微服務的註冊處。這樣的方案要求更多的技術投資，並且需要小心處理，保證發現服務本身不會成為單點故障點（single point of failure，spof）。微服務啟動時，會將自身註冊到這樣的註冊服務裡，微服務關閉時則會將自身移除。如果微服務意外終止或者死鎖了，它們也會被自動地從註冊處移除。記住，發現服務並不僅僅是找到什麼在執行——知道什麼不可用也非常重要。
如果某個微服務在應用程式裡的確很有價值，那麼使用其的開發人員會不斷增加，隨著使用的增長，流量會激增。新的微服務有設計良好的擴充套件計畫，這對於運營團隊非常重要。
微服務是否能自動擴充套件？是否有狀態駐留在記憶體裡，導致自動擴充套件和請求路由很困難（比如，使用者會話狀態）？如果有的話，分割槽策略是什麼？
如果能事先了解大幅擴充套件時微服務的哪個部分會首先出錯會很有用。對於由資料庫支援的服務而言，計算能力（比如，位於自動擴充套件組裡的ec2例項）通常能夠持續擴充套件直到資料庫不堪重負。對於真正的無狀態服務而言（比如，不從資料庫讀取也不寫入的計算型微服務），首先會出問題的可能是位於例項集群之前的負載均衡器。這兩種情況都有對應的解決方案，不過在部署微服務的第乙個版本時，這些方案並不一定需要就位。但是，需要詳細了解新的微服務的限制，這樣才能在生產環境能力達到上限之前就知道服務擴充套件的天花板位於何處。
即使微服務的範圍非常小，它也可能依賴於系統裡已有的其他服務或者monolith程式。比如，大部分應用程式事務需要檢視客戶資訊，因此用來訪問客戶記錄的服務通常是提供業務價值的大部分服務的依賴。
如果新的微服務依賴於任何其他服務，當這些依賴服務故障時會發生什麼至關重要。使用固定的請求超時時間是個好的開始，但是新增流程斷點可能會更好。所依賴服務的所有者應該也希望其使用者在故障發生時使用類似指數延遲的技術，來避免 驚蟄問題 的發生。
這種場景很好測試，因為其測試只需要所依賴服務不可用即可。但是，務必記住所依賴服務api的呼叫失敗可能會有 很多種原因 ，這些故障表現也各不相同。
取決於在新微服務的高可用能力上投資多少，也取決於其支援何種事務，這可能並不是個重要的問題。比如，乙個簡單的運營日誌微服務，通過udp非同步傳送資料，可能出現幾分鐘的故障，但是這對於應用程式的主要業務事務並沒有任何影響。但是，非同步處理信用卡事務的微服務如果發生故障，則可能嚴重損壞電子商務系統，那麼這種故障場景就必須嚴格測試，並為之做好應對準備。
因此，即使範圍有限的微服務（或者其開發人員）不需要擔心系統的其他部分如何使用這個新元件，系統級別上關於每個服務如何依賴於其他服務的考量能夠幫助避免連鎖故障，也能幫助確保應用程式的整體效能。
可能大家傾向於認為docker這樣的容器技術，和ansible這樣的部署自動化工具使得公升級變得不那麼重要，但是微服務的維護需要考慮很多這些已有工具無法解決的其他方面的問題。
定義公升級策略，並且決定微服務支援的部署複雜度級別十分重要。想用新版本取代舊版本時， canary測試 ， 藍/綠部署 ，特性標誌，以及 response diff'ing 這些，比起簡單的滾動公升級而言，要求更多的時間和投入。
為微服務api的公升級定義界線和策略對於依賴於其的元件更為重要。比如，一次只允許某個api的json schema新增乙個改動，這樣使得服務能夠持續改進，並且不要求其使用者每次都必須隨之公升級。但是，向xml響應負載裡新增新字段時，如果其使用者每次都做xml schema驗證的話就會導致嚴重的問題。因此如果規律公升級新的微服務，向其api物件新增越來越多的字段，那麼需要在其文件裡清晰記錄，告知其服務的使用者。
最後，要了解如果新版本有問題時，微服務如何回滾，以及如何考慮「回滾判斷指標」。
如果你的公司已經有了應用程式監控的標準，那麼就應該使用這些標準，借助已有的監控生態系統。注意不能忽略已有標準——或者更為嚴重地——使用新的監控工具而運營團隊之前完全沒有使用過。
如果你的公司還沒有高質量的應用程式監控系統，向應用程式新增新的微服務可以作為推動監控系統搭建的起點。這對於之前都是監控大型monolithic應用程式，現在才開始向微服務架構遷移的企業來說尤其重要：一系列互相連線的微服務的運營監控需求要比單個大型的monolith程式的監控需求複雜得多。
無論選擇哪種監控方案，是自己開發，選擇開源軟體還是商業軟體，微服務的開發人員都應用能夠完全訪問其元件的監控和度量資料。如果缺失這樣的透明度，那麼就無法實現完整的反饋迴路，開發人員就無法知道如何在生產環境裡改進其服務，也無法在發生問題時幫助快速診斷出問題所在。
並不要求大家對上述10個問題的每乙個都有特別詳細的答案，但是需要對每點都加以考慮，並且知道微服務可能會帶來的架構上的限制。比如，一開始新的微服務部署時可能並沒有考慮災備和域故障容忍，隨後公升級來包含這樣的能力。了解微服務當前能做什麼，不能做什麼至關重要，思考上述問題的答案能夠幫助持續改進服務，最終演進成為成熟的，彈性的，可靠的系統元件。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
譯者介紹
崔婧雯，現就職於ibm，高階軟體工程師，負責ibm websphere業務流程管理軟體的系統測試工作。曾就職於vmware從事桌面虛擬化產品的質量保證工作。對虛擬化，中介軟體技術，業務流程管理有濃厚的興趣。
Jhipster 建立微服務
生成步驟 生成getway 專案 執行命令 yo jhipster 選擇getway 專案 執行getway registry 執行微服務 請求微服務方式 http localhost 9000 airportservice api books 前半部分 http localhost 9000 是g...
使用micro建立微服務
micro是乙個工具集，用來幫助開發者建立和管理微服務。它包括兩部分 另外go plugins作為一組外掛程式，在開發過程中也是必要的。通過外掛程式，我們在服務發現 非同步訊息和傳輸協議等方面有了更多的選擇。go micro的設計目標是簡化微服務的開發和分布式系統的建立。在golang 1.14以後...
微服務建立 Ubuntu搭建GitLab
ubuntu呢，用的國產麒麟，可能對於用習慣了windows作業系統的人來說使用ukylin會很難受吧，開發的人倒沒什麼，不過就是命令列的問題 那麼，怎麼搭建乙個完整的gitlab呢，一步步來操作吧，按ctrl alt t開啟dos 1 首先安裝依賴包 sudo apt get install cu...