假如你正在運行的微服務少於100，那麼你或許可以規避這些問題，但如果將服務擴展到任意更大的量級，這將帶來其自有的問題，為了使系統高效運行，你需要解決它們。 1：組織性孤立和蔓延 Conway法則的反模式表明，公司的組織結構能夠映射其軟體架構。Fowler-Rigetti稱，一家向微服務遷移的公司經常 ...
假如你正在運行的微服務少於100，那麼你或許可以規避這些問題，但如果將服務擴展到任意更大的量級，這將帶來其自有的問題，為了使系統高效運行，你需要解決它們。
1：組織性孤立和蔓延
Conway法則的反模式表明，公司的組織結構能夠映射其軟體架構。Fowler-Rigetti稱，一家向微服務遷移的公司經常以產生幾個孤立的微服務團隊告終。另外，由於沒有人知道其他團隊正在做什麼，以及最佳實踐無法分享，最終導致技術無方向蔓延。
“微服務開發者和開發者團隊就如同微服務一樣”，Fowler-Rigetti說，“他們在專註且只做一件事時是非常棒的”。對於特定團隊而言這很好，然而當開發者想要改變團隊時，它就會成為問題。
Fowler-Rigetti稱，她曾聽聞改變了團隊的開發者說自己像是換到了一家新公司，因為所有的規則都不同了。
2：花式故障
系統越大越複雜，就意味著越容易出現故障，因此這個系統將會失敗。它們通常產生於一些點。隨著成千上百的微服務被部署，它們中的任何一個均有可能出現問題。請點擊此處輸入圖片描述
3: 資源競爭
微服務向組織提供服務，就如同生態系統一樣，它們十分複雜且脆落，Fowler-Rigetti如是說。
硬體和工程資源均是稀缺昂貴的。不像單體應用，微服務無法通過無限制的硬體或者增加人數來解決問題。她說，這起初可能確實有效，但是隨著時間的增長，你的微服務的數量越來越多，這將無法適應擴展的需求。
那麼當存在成百上千的微服務時，組織應該如何劃分優先順序？誰得到優先順序？誰來做決定？
4: 關於微服務的誤區
這些誤解在開發者和經理之間蔓延，這對於脆落的微服務生態而言是十分危險的。
其中最流行的神話：微服務就是狂野西部。你可以做你所想，使用任何代碼、資料庫、程式語言等，只要你完成工作後，其他服務就能夠依賴它。這樣做的代價是巨大的，因為系統最終可能以不得不維護多個庫和資料庫版本。
另一個危險的神話：微服務就是一顆銀彈，它們會解決所有問題。Fowler-Rigetti對此作出了否認。微服務應該是公司架構在觸及其擴展能力上限時而做出的演進過程中的一步，而非擺脫工程難題的一條捷徑。
5. 技術蔓延和技術債務
當開發者團隊使用不同語言，各自的基礎設施以及定製腳本，來構建微服務結構時，組織最終會得到一個巨大的系統，其中任何一件事都會有一千種不同的做法。
它最終可能會是成百上千的微服務，其中的一些正在運行，大部分在維護中，而另一部分則是被遺忘。“你的腳本在機器的某個角落乾著只有上帝才會知道的事情，沒人會想整理它們”，Fowler-Rigetti說，“他們都希望搭建下一個新玩意”。
至理名言：任何定製化都是不可擴展的。架構技術是程式員繞不開的話題，關於分散式，微服務，源碼，框架結構，設計模式等這些技術我都分享在群650385180，可免費下載。希望可以幫助在這個行業發展的朋友和童鞋們，在論壇博客等地方少花些時間找資料，把有限的時間，真正花在學習上，我把這些視頻分享出來。相信對於已經工作和遇到技術瓶頸的碼友，在這個群里一定有你需要的內容。
6. 固有的信任缺失
由於微服務存活於複雜的依賴鏈中，它們互相依賴，並且也沒有標準化和通信，因此這裡就無法確定依賴是可靠的。她說，根本沒有任何方式獲知微服務對於生產流量是否可信。
走出困境
如果你是一名開發者，並且正轉向微服務，對於上述司空見慣。你要如何走出困境？
第一步，讓組織各級買賬。為了使微服務切實可行，推行標準化不僅是最佳實踐，更是關鍵使命。它需要在棧的各層被採納和實施。
接下來，公司需要“貫穿整個組織，在所有微服務上把控高層架構、運維和組織標準，而非以逐個服務為基礎”，她解釋道。只有當一個微服務符合所有這些標準，它才可被視為“生產就緒”。
標準化訴求
Fowler-Rigetti分享的上圖從微服務視角展示了微服務環境的各層級。其中微服務團隊只需要工作在第4層。
為了使微服務變為可能，需要將其他內容從中抽象出。這將會制約技術蔓延以及並增加可計量性。
很多人認為他們通過微服務無償地獲取了可擴展性，但當你遇到一個大到瘋狂的規模時，就不是如此了。
下一步，需要就“產品就緒”的要求達成一致，並且這些要求需要成為工程文化的一部分。她說，工程師通常視標準化為障礙，但在微服務的新世界里，每個服務都屬於一個複雜的依賴連，此時障礙不再。
微服務不應損害整個產品或系統的完整性。
什麼使服務成為"產品就緒"？
Fowler-Rigetti給出了一個列表：
穩定性
可靠性
可擴展性
性能
容錯
災備
監控
文檔
Fowler-Rigetti對此做了深入解釋：
穩定性和可靠性
使用微服務，會帶來更多的變更和更快的部署，這就導致了不穩定性。她稱，一個可靠的微服務應該是能夠被其客戶、依賴和生態所信任的。她認為穩定性和可靠性是息息相關的，大多數穩定性需求會伴隨可靠性需求。一條在進入生產環境前具備多個階段的部署流水線就是一個很好地的例子。
可擴展性和性能
Fowler-Rigetti稱，大多數人認為他們能夠通過微服務無償獲得可擴展性，但這對於巨大的規模而言並非如此。隨著流量的增加，它們應該得到適當的擴展。
許多語言在設計上就無法做到高效的擴展，因為它們無法做到併發、分區和高效。這使得用那些語言開發的微服務難以得到合理的擴展。Fowler-Rigetti謝絕指出具體的語言，但她說，“我很肯定自己能想到一些。”
她解釋道，可擴展性是指微服務能夠處理多少請求(譯者：可擴展性是指系統為應對業務增加而對自身進行相應擴展的能力，有些時候也作伸縮性，即在業務縮減的時候，系統規模做相應的收縮)，性能則是指服務能夠多好地處理這些任務(譯者：這應該叫QoS)。一個高性能的服務應該合理地使用資源、高效地處理任務、快速地處理請求。
如果微服務無法得到預期的擴展，那麼其出現故障的概率會急劇上升。延遲的增長會導致低下的可用性。
容錯和災備
為了保證可用性這個終極目標，開發者需要確保任何微服務出現故障後均不會導致系統宕掉。因此開發者需要知道所有的故障模式，並且做好備份工作，以應對故障的帶來。
成功災備的關鍵是健壯的彈性測試，它包括代碼測試、負載測試，以及含其它主動性測試的混沌測試。每個故障模式都應該在生產環境中復現，以觀察能否“存活”。
給定微服務環境的複雜度和複雜的依賴鏈，故障是難以避免的(譯者：總覺得這句話本來就有問題)。微服務必須能夠承受來自內部和外部的故障。
監控和文檔
Fowler-Rigetti說，“我發現在微服務架構中，系統的狀態永遠和上一秒不同。如果你不知曉系統的狀態，在系統故障時你將無法得知，這會導致最終的失敗。”
擁有一款好的監控工具來展示系統在任意時刻的狀態，這是很關鍵的。缺少良好的監控工具是造成服務中斷的第二大原因。
日誌是監控的本質部分，因為你將幾乎不可能復現bug。知曉發生了什麼的唯一方式就是確保你在那時記錄了系統的狀態。唯一的手段便是合理的日誌記錄。
這使得我們能夠輕鬆信任服務。
文檔對於每個開發者而言都是阻礙，但它確實是關鍵的。它移除了技術債務，並使得團隊新成員能夠趕上進度。
