微服務的概念出現(xiàn)不是一天兩天了，但是要追溯它的源頭還要看SOA，畢竟微服務只是一種比較現(xiàn)代化的細粒度的SOA實現(xiàn)方式，并非從天而降突然出現(xiàn)的。但不得不承認，IT架構實現(xiàn)了從all in one到微服務架構轉變，微服務架構模式（Microservice Architect Pattern）開始被越來越多的企業(yè)所接受。
根據ThoughtWorks的首席科學家，馬丁·福勒先生的定義：“微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協(xié)調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相溝通（通常是基于HTTP協(xié)議的RESTful API）。每個服務都圍繞著具體業(yè)務進行構建，并且能夠被獨立的部署到生產環(huán)境、類生產環(huán)境等。另外，應當盡量避免統(tǒng)一的、集中式的服務管理機制，對具體的一個服務而言，應根據業(yè)務上下文，選擇合適的語言、工具對其進行構建。”
如何避免盲人摸象
比如某大型互聯(lián)網公司的技術主管就深感微服務架構優(yōu)勢多多，比如復雜可控、靈活可擴展、獨立部署、開發(fā)展對性強等等，當然最重要的還有降低TCO，畢竟在微服務架構模式下，當某一組件發(fā)生故障時，不會發(fā)現(xiàn)單塊架構系統(tǒng)的進程內擴散等弊端，故障會被隔離在單個服務中。
看起來好處多多，但是該部門程序員卻表達了不滿。因為在他們看來自己做了很多無用功。而且無論是分區(qū)的數據庫架構還是對微服務架構的測試都有著極大的挑戰(zhàn)。Nginx認為：“微服務”強調了服務大小，實際上，有一些開發(fā)者鼓吹建立稍微大一些的，10-100 LOC服務組。盡管小服務更樂于被采用，但是不要忘了這只是終端的選擇而不是最終的目的。微服務的目的是有效的拆分應用，實現(xiàn)敏捷開發(fā)和部署。
ohn Allspaw與Adrian Cockcroft爭論微服務
由此可見，針對微服務這一熱門話題，并沒有絕對的好壞之分。筆者認為，企業(yè)在選擇IT架構模式時應該根據自身需求來平衡，如果只需要建構一個簡單的應用，那大可不必用微服務架構，單體式的架構可能更適合你；如果企業(yè)需要建構復雜應用，微服務架構化整為零的功能還是值得肯定的，但是在應用過程中微服務也有自身缺點，需要警惕。
京公網安備 11010502049343號