框架
專案和人類一樣，總是會死亡的，有時候會突然死亡，有時候會自然死亡；在自然死亡這一邊，有的人去世的很早，有的人則壽命很長，長壽的人，通常都是生活更規律的；專案也一樣，框架更好的專案活的更久，框架不好的專案，上線同時就死亡了。
框架是一種規律，他並不是保證專案成功的基礎，他只是讓專案存續更久，存續更健康的依賴，他可以讓病人在重病時，依靠藥物還能簡單自理，而不用躺著病床上輸液。
微服務框架
微服務本質上是用於拆分業務的，因為業務被拆分成了多個服務，所以，為了保證被拆分的服務的健康，使用請求分流，服務生降級，熔斷等技術來維持服務的高可用；因為服務被拆分了，服務日誌也跟著被拆分了，所以為了保證異常排查的效率，需要進行日誌收集。
框架是架構師的工具，微服務框架也同理，它總歸是要服務於專案的。所以，我們在搭建微服務框架的專案時，不用太糾結微服務的概念。比如，你的微服務專案沒有做熔斷，有人過來說它不是微服務，其實你是不用在意的；作為架構師，你要知道，你是服務於專案的，如果你衡量的人員，進度等一系列客觀因素後，判斷熔斷和升降級可以不做，那就可以不做，保證進度才是第一要務，要相信自己寫的框架，即便沒有熔斷和升降級也可以健康運轉好一段時間。但是，如果你做的是微服務開源框架，這些功能就是必須的了，架構師可以不用，但框架不能沒有。
架構師
很多人認為學會微服務了，就可以當架構師了；其實不然，當架構師並不一定要會微服務，同理會微服務也不見得可以當架構師。
其實，微服務的概念並不難，相信很多高階軟體工程師只要百度幾天，然後消化一個月，基本上都能理解的七七八八。那麼，這些高階軟體工程師就這樣步入架構師了嗎？理論上不是，在沒有特別詳盡的掌握細節之前，我認為都沒有架構師的水平，但這並不代表他們做不了架構師的崗位。
程式設計師有個特點，他們對自己沒完全掌握的東西，有著天生的不自信，所以他們在自己未學會架構之前，是不敢應聘架構師的。但有一種高階程式設計師是不一樣的，他們本身就不是特別專研技術，並不致力於提升開發效率，他們相對更擅長溝通和寫文件，我把他們稱為【沒有腿的程式設計師】。他們對技術沒有天然的畏懼，所以他們學習了概念就敢應聘，理解的概念就有了自信。當然了，他們是無法落地的微服務或其他框架的，因為他們沒有腿。不過他們善於向老闆誇大專案難度，然後招聘很多很多的人員，並且善於用人，他們會把熔斷，升降級，日誌管理，閘道器、服務查詢等功能分別讓普通的程式設計師來開發，然後出現問題就把問題定義為團隊管理問題，然後開始搞devop或其他概念來管理團隊。當然，結果通常是需求和程式碼都亂的像一鍋漿糊，這也是祖傳程式碼出現的最基礎的原因，因為專案的起手式就亂了，後面自然就是越畫越黑。
我有一種與眾不同的認知
在招聘網站上，我們經常會看到招聘高階程式設計師或架構師要求會微服務，但同一城市不同公司給出的工資可能差一倍。仔細閱讀招聘需求，我們會發現，其實他們的要求都一樣，那為什麼工資差距這麼大呢？
我是這樣理解的，有些公司招聘的就是普通程式設計師，他們只是未來、可能會用到微服務；有些公司已經在做微服務了，而且大概率已經做的滿頭包了，所以他們需要招聘一個有經驗的高手。
在應聘這樣的崗位時，【沒有腿的程式設計師】是領先我們一個身位的，這是為什麼你技術已經不錯了，卻總是應聘架構師失敗的原因，因為公司面試過很多人，有一堆【沒有腿的程式設計師】都表現優異，所以公司無論怎麼篩選，都不會選擇你做架構師。
所以，想做架構師，先包裝自己，腿是可以慢慢長出來的，【沒有腿的程式設計師】在架構師的崗位上幹一幹，如果真把腿長出來了，那他們可就不止領先我們一個身位了；不過通常他們是很難二次發育的。
微服務必死
我們應該都聽過做微服務必死，中臺必死吧；這是因為微服務專案的失敗率非常高。通常人們把它歸結於餅大嘴小，累死的；但，其實他們死亡更多的原因是因為使用了不正確的領導；因為微服務雖然很消耗團隊，會讓小團隊疲憊翻倍，但並不是無法做專案的，微服務專案失敗率如此之高，跟微服務本身沒有必然關係。其實，這樣的領導，搞微服務是死，他搞前後端分離也一樣能把專案搞死。
結語
框架是死的，人是活的，把專案失敗的原因歸結於開發模式的，都是學藝不精而已，
----------------------------------------------------------------------------------------------------
注：此文章為原創，任何形式的轉載都請聯絡作者獲得授權並註明出處！
若您覺得這篇文章還不錯，請點選下方的【推薦】，非常感謝！
https://www.cnblogs.com/kiba/p/15497173.html
