前言
筆者從2013年加入ThoughtWorks至今共4年時間。在這4年時間里，我分別以開發(fā)人員、DevOps工程師、DevOps咨詢師、微服務架構師以及微服務咨詢師的角色參與了共計7個產品和項目的微服務咨詢和實施。其中有成功，有失敗，有反思，更多的是學習和總結。以下是我這些年來在微服務咨詢上的經驗總結，希望能給陷入微服務實施困境的人帶來一些幫助。
難點1：“一步到位”的認知錯覺
這些年微服務大紅大紫，但是真正能夠拿出來做為可實踐案例的少之又少。大部分的微服務案例只能看到微服務架構的“演進結果”，但是看不到其“演進過程”。這就像每個人可以看到一個架構的高峰，卻看不到攀登高峰的路徑。
這就造成了一個假象：微服務的架構是通過能力極高的架構師一步到位設計出來的。
這和很多團隊自上而下的架構設計感受很相似。于是架構師們蜂擁而至，各種分析方法論層出不窮，討論和分享絡繹不絕。然而真正落地實施的卻很少，使得微服務在網(wǎng)絡上慢慢變成了一種“玄學”：微服務的實施一直在“理論研究”的階段。
這違反了軟件架構的最基本規(guī)律：架構是通過解決當前的需求和痛點而演進的，無法根據(jù)沒有出現(xiàn)的問題和痛點進行設計。因此，一步到位的、整體的微服務架構設計完全沒有必要。況且一個集中化的設計，很難體現(xiàn)微服務的輕量級優(yōu)勢。
我相信技術一定是向不斷降低成本的方向發(fā)展的。如果新技術沒有降低成本反而提升了成本，要么這個新技術有問題，要么是姿勢不對、走錯了路。
因此，準備實施微服務一定要有一個長期的思想準備。不過跨過了最初的門檻之后，剩下的工作可以被復制、而且速度會越來越快。
難點2：“架構師精英主義”
很多產品對架構師的依賴很大，即“架構師精英主義”：認為只有這個組織的“技術精英”——架構師才可以完成該產品的架構，而團隊其它成員只需要實現(xiàn)架構師的設計就可以。這是大型企業(yè)和大型系統(tǒng)的常見問題，來源于長期以來重量級企業(yè)級架構的習慣。
而微服務則類似于一種“敏捷邊際革命”：即由一個不超過2~8個人的小團隊就可以完成的輕量級架構。而且對于這種規(guī)模的團隊而言，即使把整個微服務團隊從產品團隊移除也不會對整體產品的研發(fā)進度產生影響。因此，即使失敗了也不會帶來太多的損失。不過，當?shù)谝粋�微服務改造成功，那么成功經驗的復制帶來的乘數(shù)效應卻能帶來很大的收益。
從架構改造投資的風險收益比來看，這是非常劃算的。
因此，微服務團隊完全沒必要大張旗鼓，只需要兩三個人就可以動工。但是，誰也沒有微服務的實踐經驗啊，萬一失敗了怎么辦？
這就帶來了下一個難點。
難點3：缺乏一個信任并鼓勵創(chuàng)新的環(huán)境
面對未知的領域，失敗再所難免。而處在這個不確定性頻發(fā)的世界，成功和失敗已經不再重要：也許今天的失敗，明天再看就是成功，反之亦然。
成功只是表明結果符合自己的假設預期，而失敗僅僅意味著結果不符合自己的假設預期。但是無論成敗，我們都能在行動的過程中有所學習和反思，而這樣的經驗才是研發(fā)活動中最有價值的。
然而，很多組織，尤其“精英主義”的產品團隊，責任和壓力往往從上至下分解。由于組織龐大，金字塔的結構往往會構建一種以“不信任”為基礎的制度。這種制度營造了一種“寧可不作為，也不能犯錯”的文化。由于上層需要對失敗負責，使得所有創(chuàng)新只能停留在上層，難以落實推進。在這種情況下，組織的長期合作形成了穩(wěn)定的工作習慣和思維定勢，并形成了利益平衡，這會使得整個組織在面對創(chuàng)新的時候“卡殼”。
當微服務以一種政治任務從上而下派發(fā)的時候，為了避免失敗，團隊內部會相互推諉。通過不斷的分析討論和設計來論證這個事情的難度。在我看來，只要想搞，就一定能找到辦法，而不是先設想出一堆還沒有遇到的問題和責任。在行進中解決問題是比設計和討論更加有效率的方法。
而組織解決“卡殼”的辦法就是引入“背鍋俠”：例如新聘請的架構師或外部咨詢師，來完成這個事情。出了問題就不用自己來承擔責任了。這樣雖然是解決問題的一種折中辦法，可以讓事情毫無風險的執(zhí)行下去。但這是一種短期效應，無法解決組織本身的創(chuàng)新窘境，長期依賴外部力量來解決最有價值的問題不會讓自己提升，反而形成了對外部力量的依賴。對于凝聚組織來說不是一件好事。
只有打破當前的工作習慣和思維定勢，充分認識到創(chuàng)新的困難、風險以及價值，才可以占領創(chuàng)新的高點，吸引人才。
難點4：微服務技術棧的“選擇困難癥”
由于“精英主義”的架構師需要擔負很大的責任和壓力。他們必須要為微服務架構謹慎的選擇技術棧。因此會在不同的技術棧之間不斷嘗試。對于習慣了在大型研發(fā)組織里“精心設計，加班生產 ”的架構師而言。“長設計，慢反饋”節(jié)奏似乎是理所應當?shù)摹?/div>
微服務開源社區(qū)的快速發(fā)展滋長了“架構師焦慮”：如果采用落后的技術會被同行鄙視，被不懂技術的老板鄙視，甚至被下屬鄙視。因此架構師們疲于在各種新型的技術棧之間比較和學習。此外，不熟悉技術往往會增大風險，架構師就需要更多的時間研究。帶著“一步到位”的架構幻想對微服務技術棧精挑細選，而不會采用現(xiàn)有低成本的方案快速迭代的解決問題。
微服務的核心在于采用“小規(guī)模，快反饋”的機制降低軟件系統(tǒng)的復雜性并通過虛擬和自動化技術分散風險，從而及時應對市場變化帶來的各種挑戰(zhàn)、進行快速銷售創(chuàng)新，獲得市場的反饋。而不僅僅是利用到了時下新興的語言，編程框架或工具。
學習和實踐是相輔相成的過程，在實踐中學習，并把學習到的知識應用到實踐中。這不同于準備一場考試：先停下來學習，準備好了再全力以赴。
以上四點會讓大型組織在微服務實施中“卡殼”，這往往會導致微服務實施忽略最重要一點，也是我認為也是核心的一點。
難點5：對微服務的技術變革預估過高，而對微服務帶來的組織變革預估不足
作為架構師，永遠要不要低估康威定理的威力：“設計系統(tǒng)的組織，其產生的設計和架構等價于組織間的溝通結構。”
從制度經濟學角度來講，軟件產品本身就是企業(yè)內部組織（員工）和外部組織（用戶）溝通制度的計算機程序表達。這個制度一定會朝著縮短組織內外部溝通成本的方向發(fā)展。
因此，系統(tǒng)架構一定是和組織架構相吻合的，如果不吻合，勢必會阻礙組織的漸進。
這就引出了一個推論：如果企業(yè)組織的架構不是唯一的，那么微服務的架構方案也不是唯一的。
當架構和組織結構相一致的時候，一切都會很順暢。反之，就會出現(xiàn)各種問題。
這個關系就像鞋和腳的關系，只有穿上合適的鞋，走起路來才會舒服。過大過小的鞋都無法讓你加快前進的步伐。當然，你可以選擇買鞋（引入產品），雖然并不是很合腳，但還可以湊合穿，只是在換鞋的時候你不得不停下來試。你也可以花高價為自己定制一套，這個不會讓你在短時間內走得更快，只會越來越合腳。
如果所有人穿上了新鞋，都能跑得很快，只有你不能，那么這就不是鞋的問題，而是你腳的問題，這就不是換鞋能解決的了。你得先把腳的問題解決了，然后再看鞋的問題。當然，也可以通過鞋來矯正腳，只不過會花些功夫，但一定會比不停的換鞋更加有效。
很不幸，大多數(shù)的組織并沒有準備好迎接微服務架構帶來的組織變化。仍然把“系統(tǒng)架構問題”和“組織問題”割裂成兩個不同領域的問題：微服務是技術問題，組織問題是管理問題。
有競爭力的組織，是能夠通過融合優(yōu)勢達到1+1>2效果的組織。而不是把優(yōu)勢割裂開，讓1+1<=2的組織。因此，技術問題和管理問題并不是兩個問題，而是同一個問題的兩個側面。
因此，如果你的組織結構是去中心化的小團隊結構，那么不用擔心，你的應用架構會朝組織架構的方向演進。反之，如果你不是一個去中心化的小團隊結構，那么微服務的架構會和組織架構格格不入。
如何解決這些問題？
作為微服務的實踐者，對微服務不應該是“葉公好龍”，僅僅停留在研討的層面。而應該采用敏捷和精益的方式迅速開始，在行進中解決碰到的問題。每個組織的組織結構和業(yè)務結構都有所不同，微服務實施所面對的挑戰(zhàn)也截然不同。在實施的過程中快速學習并改進，沒有必要進行周期較長的總體設計。
關于如何解決本文提到的5個問題，請參考下篇《提升微服務實施效率的7個步驟》。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題：微服務進展緩慢的5個難點
本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839621082.html
本文轉自：e-works制造業(yè)信息化門戶網(wǎng)
本文來源于互聯(lián)網(wǎng)，拓步ERP資訊網(wǎng)本著傳播知識、有益學習和研究的目的進行的轉載，為網(wǎng)友免費提供，并盡力標明作者與出處，如有著作權人或出版方提出異議，本站將立即刪除。如果您對文章轉載有任何疑問請告之我們，以便我們及時糾正。聯(lián)系方式：QQ：10877846 Tel：0755-26405298。（請勿發(fā)郵件，由于垃圾郵件眾多，有可能會被當作垃圾郵件處理掉，同時現(xiàn)在很用郵件處理事務了，郵件處理時效期為3天，如急件請直接QQ聯(lián)系。）
相關文章
