架構師在軟件行業一直有很高的位置，並且在開會中的架構師都帶有主角光環。 架構師是可以說是軟件的設計者，運用我們學會就會忘記的23種設計模式、企業架構模式、面向對象編程，來設計系統基礎架構。基礎架構開發完成後，程序員就可以愉快的在系統的基礎框架裏舔磚加瓦，最終完成項目的開發。
微服務和架構師有什麼關係？因爲微服務也是一種架構，所以還需要架構師來設計。先不說架構師了，架構師在微服務作用放到最後說。先說說傳統的架構。
傳統的三層架構
傳統的web系統一般是採用三層架構來開發系統的，三層架構既視圖層、業務層、數據層的架構。視圖層負責與用戶交互，業務層負責處理業務邏輯，數據層負責數據的處理。一般系統上線發佈，都是打成一個包，部署在中間件中，業務代碼全在一個進程中。對於需要高可用的系統，架構會設計成集羣，web應用會運行在多個主機中。
這種架構的系統看起來沒什麼問題，不重要的系統，單例，一個進程。重要的系統，集羣，多實例。其實這種架構問題很多，不然也不會有現在的微服務模式。 傳統架構的缺點：
1、難以維護: 代碼極度臃腫，有些小系統的代碼竟然達到100m甚至1G，裏面不知有多少無用的包和個版本積累的無用代碼，代碼難以維護。 2、穩定性差： 穩定性差主要有幾個原因： 1、代碼原因：代碼越多，bug就回去越多。因爲代碼都是運作在一個進程中，某塊代碼出現問題，就會導致系統運行緩慢、不可用，甚至進程崩潰問題。 2、中間件原因：中間件也有bug，有時也會罷工，它一罷工，系統就整個崩潰了。 3、依賴系統問題：依賴系統出問題了，也可能會導致本系統最終不可用。 4、其他原因：數據庫、操作系統、硬件存儲等。 3、難以擴展： 系統不好集羣，集羣了，負載不一定好用。無法動態擴展。 4、發佈成本高： 因爲是集成到一個包，所以修改的代碼難以確定修改的範圍和影響的範圍，不知道影響範圍，有時需要全面測試，直接導致測試周期拉長，上線後修改的代碼還可能引起其他問題。
微服務是什麼？
微服務，不同的人理解不同。我的理解，微服務在軟件中，就是一種軟件架構模式。是系統的調用架構模式，是將系統分割成單獨模塊，提供api工其他模塊調用，可以單獨部署，單獨運行在服務器之中，可以說是天生的分佈式系統。
微服務解決了什麼問題？
1、穩定性提升：業務按模塊劃分，實現了進程級別、容器級別甚至操作系統級別的隔離，互不影響。運維的核心可以從解決問題轉變成主動發現問題。 2、易部署：輕量級部署，影響範圍可控，系統其他模塊可以正常運行。 3、易交付：因爲代碼較少，測試較快，說要交付週期縮短了。 4、易擴展：模塊代碼是輕量級的，容易快速擴展。
微服務的通信是什麼？ 模塊相互調用就需要通信，通信首先方式是rpc，以保證其性能。對接過soa系統開發人員可能比較清楚，soa用的是http協議，調用都是訪問網頁一樣，性能較差。可以說，沒有好的rpc框架，就不會有好的微服務。現在的rpc框架有Netty，dubbo，HSF，ZooKeeper。
微服務是不是糖衣炮彈，有沒有陷阱？ 微服務是不是糖衣炮彈，搞不好真是，爲了避免炸傷自己，有些陷阱還是要注意。
1、減少多樣性：因爲爲微服務是可以使用不用語言實現的，會增加項目的後期維護成本，最好一個項目都開發語言不要超過兩種，不要java、c、c++、c#、python、delphi、node.js、go等各類語言都來了。 2、要有熔斷機制：微服務因爲是模塊化，模塊之間調用會非常頻繁，如果沒有熔斷機制，一旦一個模塊出現問題，可能會導致調用鏈出現問題，最後導致系統完全崩潰。
3、一定要有服務監控：一定要有服務監控，最好可以監控每個服務的調用鏈，及時發現問題。
要不要用微服務？ 微服務是一種軟件組織、協作的模式。對於一般的管理系統，不建議採用微服務模式，但是可以將容易出問題或者需要與其他系統交互的模塊，進行拆分，做成微服務，這樣可以進一步提升系統的穩定性。對於大型系統是否採用，這個就需要軟件的架構師去評估了。
來源：http://ypj5.com/p/3332386066159616?spm=5176.100239.blogcont73731.15.yITCOK