最近咱們開發團隊在開發計劃中有一個小停頓，技術部門認爲如今是將應用從單體架構遷移到微服務的最佳時機。通過一個月的準備和調查，咱們取消了遷移，仍然使用單體模式。對咱們而言，微服務不只幫不上忙，反而會影響到開發計劃。咱們瞭解微服務大約是在一年前，可是很驚訝地發現它並不適合咱們。後端
本篇文章把咱們的經歷寫出來，可能會對你們都有借鑑意義。 跨域
1、發現問題以及早期妥協微信
一、咱們嚴重依賴第三方網絡
咱們的應用是整合外部現有產品和業務規則給用戶展示一個友好界面的UI。客戶是一家UWP app，後臺有相應服務在第三方域和咱們之間交換數據。架構
對第三方的依賴嚴重影響咱們選擇微服務。例如，應用常常要在不一樣域之間轉換功能，使得第三方域看起來像是徹底不一樣的一個域，若是在咱們之間有一個單一服務狀況還不算太糟。然而，整個域交換在分解成多個微服務過程當中就看起來很怪異了。是咱們的微服務跟第三方的分解不一樣嗎？咱們複製了全部服務的先後端需求嗎？仍是咱們分解了本身的微服務，仍然須要一個微服務從第三方獲取信息？全部這些問題看起來都跟微服務指南相背離。app
咱們和第三方合做很緊密，常常一塊兒協做發佈版本。微服務的好處在於每一個團隊均可以不受影響獨立發行服務，而跨公司合做則失去了這種好處。負載均衡
微服務另一個好處在於，每一個團隊只須要完整設計本身的業務問題。而咱們，做爲一個和第三方徹底獨立的公司團隊，這種重構看起來不可行。編輯器
二、咱們不能有效分離微服務微服務
咱們實在找不出應該從哪一個單體應用下手。因而咱們在域模型之間連線，以決定要建立哪些微服務。然而，一旦這麼開始作，發現不少共享業務邏輯影響着微服務域的劃分。若是將微服務劃分的更細小，只能帶來更多的耦合關係，處處都須要消息總線，消息可能會出現大爆炸。工具
緣由在於咱們的單體式應用是爲一個業務邏輯服務的。咱們爲用戶方便建立了跨域和組的不少工做流，本質上，UI在過去四年中就是將各類東西整合到了一塊兒。
另外，咱們還誤解了微服務如何被隔離，以及低估了服務之間正確邊界選擇的重要性。惟一能作到的就是爲了實現一個標準功能，從而須要將全部相關微服務同時升級，由此要求每一個微服務都不能被某個單獨團隊擁有。
三、共享微服務
咱們大約有12個開發人員分佈在兩個功能團隊和一個支持團隊。工做波動性很大，沒有專職負責團隊。全部團隊同時接觸同一批代碼很正常，不能將某個微服務指定給一個團隊。
考慮架構時候必定要記得Conway's Law，其意思是軟件架構會模仿組織和團隊架構增加。微服務架構對於不一樣團隊負責不一樣業務邏輯是比較有效的，然而，共享代碼功能的工做模式最好採用單體式架構。
四、平臺並無準備好
各類問題意味着至少六個月內，須要在IIS內並行運行微服務和單體式應用。咱們不會訪問與微服務相關的工具，如容器、Kubernetes、服務總線、API網管等，也就意味着與其它微服務之間通信有很大障礙。所以，咱們決定每一個微服務都複製與存儲層轉換相關讀服務的共享邏輯。由於不能正常拆分服務，也就意味着必須承擔大量複製工做量。例如，對於某個複雜並且基礎的業務邏輯，必須複製黏貼並維護至少4個計劃中的微服務。
五、沒有將來清晰圖景
開發團隊只有六個月內粗略的構想，並且業務更改也很頻繁（業務更改需求也是司空見慣的事情），這些讓微服務化更加充滿不肯定性，由於即便在短時間也沒法預知會出現什麼連接。微服務之間的複雜性會增長嗎？花了幾個月分離的服務會回到過去嗎？儘管咱們今年早些時候作過一些PoC，可是由於業務需求的更改不得不放棄。
六、架構緊耦合
咱們只有一個很窄的時間窗口，恰好能把單體式應用分解成列出來的微服務，並且沒有冗餘時間應付可能出現的改變，也沒有plan B，咱們被本身給卡住了。由於咱們在計劃階段就發現了不少問題和挑戰，更別說實施階段了，開發團隊很是有壓力。
七、缺少經驗
考慮到風險和時間壓力，並且架構師和實施專家也都沒有任何特殊經驗，加上沒有標準工具能用，咱們只能靠本身來實施，這些都更加惡化了狀況。和其餘微服務大拿溝通後，他們也都發出了不少警告，並給出了很多之前並無的架構建議，指出了咱們在域模型之間畫線的順序。
到目前爲止，因爲時間緊任務重，咱們的計劃包括了不少不一樣於標準微服務的妥協方案。由於缺少專家，這看起來更像一條不歸之路，開發團隊愈來愈焦慮。
2、再次拷問咱們的目標
一、是否解決了痛點
一旦前方佈滿了困難，就失去了目標，咱們暫停下來，意識到咱們並無搞明白爲何要這樣作。咱們沒有列出痛點，並且不清楚這樣作是否能夠解決痛點。更甚，微服務有可能會給咱們帶來新的問題。咱們開始反思，咱們從中會得到什麼好處？能解決什麼問題？咱們召開了更多會議討論它，但一直沒有明確的答案。
最後，咱們發如今討論微服務過程當中咱們忽略了一個很重要的痛點，並且沒有足夠的時間來解決這個問題，也就是咱們不能考慮微服務或者其餘東西了。
二、潛在收益是什麼
這時候咱們開始反思微服務通常意義上會帶來什麼好處？
三、自治
微服務使得團隊能夠控制全棧提供一個功能。這種區隔會減小不一樣團隊之間協同的次數，互相不影響對方的工做。
四、使團隊更加專一
單體式應用中，團隊能夠專一於全部任務。而採用微服務後，則是某項業務流程的專家。他們會理解本身區域內的業務規則和需求，知道軟件棧如何搭建，當發生改變時會很是有信心完成。
五、易於擴展
有了微服務，能夠根據性能需求擴展服務規模。而在單體式應用中，儘管也能夠水平擴展服務，可是不能獨立擴展單體應用的模塊。微服務粒度能夠增長或者減小服務能力。也許當發現性能問題時，能夠參與其餘工做，或者稍微喘口氣。
六、易於回滾
每一個功能只須要修改單一微服務，並且能夠不影響其餘團隊工做進行回滾。另外微服務還能夠減小單一錯誤對整個系統的影響。
七、易於迭代
若是有一個擴充系統的，每一個發佈都很花時間而且有風險，那麼就須要大量工做處理每次發行時的問題。微服務能夠減小溝通時間和成本，團隊能夠各自肯定合適時間。
八、採用最佳技術
團隊依賴微服務能夠選擇最佳技術方案。而單體式卻很難升級。
九、易於升級
大型應用升級都不是一件容易的事情。尤爲是要在多個團隊之間協做。相互隔離的微服務能夠每次只升級一個服務，更容易控制風險。
十、風險保護
微服務能夠將頻繁變化和不多變化的服務分隔開，減小意外發生的風險。
十一、粒度減少
小型化服務更易於理解。並且能夠保持設計一致。對比來看，單體式應用會由於不一樣團隊的意見不統一帶來不一致性。
十二、優點彙總
微服務有不少優點。可是咱們能從中得到什麼？
最終，對於沒法改變或者妥協的架構只能放棄這些優點。咱們失去了微服務帶來的隔離性。與第三方的合做減弱了從服務不相關性中帶來的好處。
3、權衡
一、大炮打蚊子
微服務也並不都是優勢，有一長串須要考慮的問題。例如，日誌，監控，異常處理，容錯，回滾，通信，消息格式，容器，服務發現，備份，遙測，報警，跟蹤，工具，共享，文檔，擴展，時區，階段，API版本，網絡延遲，健康檢查，負載均衡，CDC測試，等等。若是沒有微服務平臺，咱們要本身面對全部上面列出來的問題。由於有痛點纔要轉向微服務，可是不但無法從中獲益，還要面對一堆轉向微服務帶來的問題，咱們是何苦來呢？
二、微服務只是名義
下圖是咱們如今單體式應用和微服務的對比。：
架構上來看，新架構很像單體式，各個組件仍是緊耦合，也許咱們只是用了微服務的標籤。
三、單體式必定不好嗎
好像「單體式」就意味着落後，「微服務」就意味着先進。可是從開發團隊來看，咱們的單體式應用運行良好，基本沒有什麼問題。咱們有很好的CI/CD配置，易於配置和回滾。分支和測試策略確保問題都被提早解決。
四、似曾相識
此時，彷佛有些熟悉的感受。在我之前從業經驗也有過相似的經驗，但從沒稱爲微服務，儘管並不徹底符合微服務的規則，可是的確解決了問題並帶來相似的好處。5我的的小團隊帶領200人的開發者。這是一個巨大的C#應用，大概5%的工做經過單體式共享，其餘的共享兩節點服務。
咱們也不喜歡單體式，工做起來很慢，編譯，測試，架構改變的很快常常看到不一樣的同事出現。有時候由於一個從未聽過的同事辭職了從而延遲了整個項目，技術更新由於要和整個公司同步須要幾個月，pull申請須要整個系統批覆須要幾個星期。
同時，有兩個服務規模很小，咱們能夠很好地控制、部署、架構它。一旦有性能問題，會懷疑實例數量直到解決底層問題，不多麻煩其它團隊。咱們團隊主導了先後端開發語言的選擇。總之，咱們很專一於一個很窄的業務邏輯，每一個人都成爲了專家。
五、技術以外
越瞭解微服務，愈加現其不太適合咱們。咱們是否是太爲了技術而技術了？
還有不少其餘問題沒考慮：
有沒有專一業務邏輯的團隊？
是否可以清晰劃分域和微服務？
工做在全部團隊之間是否平衡？
團隊負載是否均衡？
單體式困難是否被分解到其餘工做中？
六、覆盤
遷移到微服務是個大爆炸，你們都停下功能開始想如何分解單體引用，即便前提還不具有。
後來證實這不是個好方法，有可能仍是個倒退。首先建立全部微服務，而後設置架構並忽略了團隊的架構。假如咱們開始時考慮團隊和業務邏輯結合，等架構成熟，並等微服務天然顯現，會更好。並且新的業務需求出現，能夠直接被放在一個新服務中。
強制上微服務，也意味着須要選擇每一個微服務的大小。一些文章建議每一個微服務至少按照一個團隊的支撐設計。其餘的則建議越小越好，一旦須要更改，很短期內就能夠完成。
領導層決定按照工做域劃分，若是須要再細分。這個決定致使上面出現的問題。後來覆盤時發現若是等待微服務天然出現，其大小其實最合適。
七、取消
隨着預約時間一每天臨近，咱們團隊持續發現愈來愈多的問題。上線四天後，仍然看不到預期的效果。因而召開了一次會議，最終取消了微服務計劃。
八、取代行動
微服務的熱度消散，也就意味着咱們沒有作好必要的調研。拋棄了微服務後，咱們也有精力去調研其餘方案。最後，咱們決定在單體應用內部劃分紅不一樣項目，更好地劃分了架構和耦合關係。
另外這種架構使得域模型更加清晰，使得將來考慮微服務更容易。
4、結論
領導層上微服務的倉促決定並沒考慮清楚挑戰和目前狀態。評估後，發現微服務並不適合咱們，須要更多的妥協。這些折衷方案把微服務帶來的好處都抵消掉了。微服務並不考慮非技術因素，例如團隊結構和工做量。幾個月調研後，咱們拋棄了微服務嘗試，決定對已有的單體式應用作一些更適合的微調。
原文地址
-
https://medium.com/@steven.lemon182/why-our-team-cancelled-our-move-to-microservices-8fd87898d952
本文分享自微信公衆號 - 架構師智庫（beijing-tmt）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。