微服務是軟體架構的銀彈嗎？或許不是。這個世界上很少有東西是百分百正確的，微服務也不例外。最近，技術作家麥可·丘奇曼（michael churchman）發文分享了在設計或重構應用程式時，哪些場景可以使用微服務，哪些場景要避免使用微服務。以下為原文編譯內容。
微服務是乙個具體的軟體服務，通常是基於應用程式上下文而定義的乙個規模合理的最小化服務。乙個應用程式可以由多個微服務組成，這些服務的部署和管理是獨立的，它們組合在一起實現了應用程式的功能。
這意味著我們可以在不重新設計或更新整個應用程式的情況下更新單個微服務，也意味著單個微服務（或多個微服務）發生故障並不會導致整個應用程式癱瘓，乙個受到攻擊的微服務也不會導致整個應用程式變脆弱。對於複雜的大型應用程式來說，微服務架構比單體架構（傳統的非微服務架構）具備更高的可管理性。
既然微服務這麼好，為什麼不都使用微服務架構呢？事實證明，適用於大型系統的架構不一定適用於規模較小的系統，在設計新系統時所使用的設計方式並不一定適合用來維護或更新已有的系統。具體來說，以下這五種場景是不適合採用微服務的。
martin fowler
曾經說過：「……除非你的系統複雜到難以管理，否則不要考慮採用微服務……」換句話說，相比其他因素，複雜性是採用微服務架構最關鍵的考慮因素。
微服務架構需要額外的開銷，比如服務設計、服務通訊、服務管理和系統資源的使用。採用微服務架構是有代價的，如果乙個應用程式無法充分利用微服務的優勢，那麼採用微服務架構所付出的代價就有點太高了。
試想有乙個中等規模、中等複雜度的應用程式，這個應用程式由乙個相對較小的團隊負責開發和維護。如果它是乙個單體系統，服務之間的通訊可以很直接，可以對一些特定的任務進行優化。對於熟悉**的小團隊來說，維護任務就相對容易。可能有時候開發會有點麻煩，但大多數時候是可控的。
如果讓這個小團隊開發和維護同樣的應用程式，但改成了微服務架構，那麼他們的工作量就會顯著增加。即使是做乙個很小的改動也需要更多的時間，甚至還可能需要修改微服務編排和管理系統。這可能會給運維和開發人員造成壓力。
並不是所有的應用程式都大到足以被拆分成微服務，如果當前規模已經恰到好處了，把它們進一步拆分成微服務不僅不會降低複雜性，反而會讓系統變得更複雜。
大部分軟體開發人員幾乎每天都要面對遺留**。如果你正在維護乙個遺留系統，那麼無論它的原始設計多麼隨意，無論它現在變得多麼糟糕，在把它重構成微服務之前，都要認真地思考一下。它正處在生命週期的什麼階段？它是乙個任務關鍵型系統嗎（比如包含了乙個不可替代的遺留資料庫）？你需要多長時間來替換整個系統？更新或者替換過程需要乙個長期詳盡的計畫嗎？
微服務架構在更新或替換遺留系統方面扮演著重要的角色，但整個過程可能很長，乙個沒有策略指引的遷移很可能會造成災難性的後果。
有些應用程式要求各個元件和服務之間緊密整合，比如那些需要快速處理實時資料的應用程式。在服務之間新增新層會導致處理速度變慢。如果系統需要快速處理資料流中的資料（例如來自自動駕駛汽車的感測器資料），那麼延遲可能是災難性的。
嵌入式應用程式通常在響應時間和可用資源方面具有很嚴格的限制，所以它們的後端通常不太適合採用微服務架構。在設計嵌入式應用程式時，從一開始就要考慮如何讓維護變得更簡單以及如何讓資源使用最優化。微服務通常在資源比較充裕的系統中容易發揮作用，可以降低系統的複雜性。
以上就是今天的內容，總之，如果你的應用程式非常大，非常複雜，為了更好地管理它，可以考慮採用微服務架構，但如果它執行得很好，那就不要盲目追趕這個潮流。
不適合創業的7種現象
不適合創業的7種現象 post by 2008 10 16 10 54 00 1 缺少長遠目標和思維高度 作為乙個真正意義上的創業者，知道自己最終想要什麼，要達到目標需要經過那裡過程，具備長遠眼光，擁有戰略意識，而作為就業者，著眼點也就是當前這兩三年，往往第一考慮的還是安全感，如何保住現有的穩定飯碗...
為什麼 Archlinux 不適合伺服器使用
寫在前面 我使用 archlinux 已經快三年了，而且最近兩年中它已經是我的主系統，工作 娛樂都是用它完成的，windows 只是用來刷刷 bios 我個人還是很喜歡 archlinux 的 kiss 哲學的，軟體包時刻跟隨上游並且保持原汁原味，滾動更新隨時體驗新特性，最喜歡的大概還是 arch ...
vecket適合和不適合的10種人（轉）
不要對veket有太高的期望，否則你只會失望 veket也許很另類，也許很酷，但絕對不應該拿來和vista對比的，veket還揹負不起這麼大的期望，一些veket狂熱追隨者的誇張宣傳，也許只能取得適得其反的後果 下面談談個人的體會，先說不適合veket的10種人 因為醜話說在前頭 不適合使用veke...