微服務架構近年來一直是互聯網技術圈的熱點，諸多新技術如 Docker、Kubernetes、DevOps、持續交付、Service Mesh 等背後都有微服務架構的影子。
微服務架構已經不是一個新概念，很多業界前沿互聯網公司的實踐表明，微服務作為一種漸進式的演進架構，是企業應對業務複雜性，支持大規模持續創新行之有效的架構手段。
在過去幾年中，有大量的互聯網公司包括很多做技術轉型的傳統企業，都在著手落地微服務架構。但在搭建微服務架構體系過程中，他們通常都會面臨相同的疑問：為什麼要選擇微服務架構？
今天我們就深入淺出，為大家解析：
- 微服務的優勢及架構特點
- 新一代微服務架構之Service Mesh
微服務架構
2014年馬丁福勒提出了微服務架構設計模式，微服務架構最核心的設計有兩點：第一，把單體服務拆分成一系列小服務；第二，拆分後的這些小服務是去中心化的，即每個服務都可以使用不同的編程語言，也可以使用不同的數據庫和緩存存儲數據。
微服務架構的設計，主要就是在協助解決軟件世界裡面快速疊代、快速交付所面臨的問題。
微服務架構的優勢
導入微服架構體現出許多優勢，包括更快的上線時間、靈活性、彈性、一致性以及相對更低的成本。
● 解耦、低耦合。解耦的構架可以讓各個功能模塊在更新的時候，完全不受到彼此的影響，更可以因為小粒度的模塊化，而可以被集成，模塊就能有重複被利用的效果。
● 更好的維護性。當微服務依照業務邏輯切割，便能切割成更小的粒度，讓開發團隊自行開發、運維與更新佈署。
● 降低系統容錯率。由於以前單體式的系統架構是整包的概念，當這個整包的功能服務系統掛掉的時候，整個系統就完全無法對外營運，而微服務的模式則是隻會影響單一微服務模塊，並且可以達到快速重啟，來降低系統錯誤造成的巨大風險。
● 低技術依賴性。由於解耦的特性，各個微服務可以各自標明合適的開發語言和套件，不會像單體式構架，必須完全受限於既有系統的框架。
下一代微服務Service Mesh
微服務架構1.0繼續演進，就變成了微服務架構2.0，即Service Mesh架構（Service Mesh）。
Service mesh的概念最早在2016年由開發Linkerd的Buoyant公司提出，之後就吸引了眾多開發者社群的注意，包括了Google、IBM、Redhat，或像Pivotal這樣的產業大咖，讓Service mesh被視為是下一代微服務構架。
研華WISE-PaaS將工業物聯網應用解耦，讓開發者能夠集成、重構的概念，也是源自於Service Mesh。
Service Mesh
Service Mesh是一個基礎設施層，用於處理服務間交互。雲原生應用有著複雜的服務拓撲，Service Mesh負責在這些拓撲中實現請求的可靠傳遞。在線上實踐中，Service Mesh通常實現為一組輕量級的網絡代理，它們與應用程序部署在一起，並且對應用程序透明。
Service Mesh的概念是將微服務的控制層和數據流的設計考察區分開來，在每個受管理的運用服務中注入一個Proxy，這個Proxy也常常被稱為Sidecar。Sidecar管理所有導向它所依附的微服務的API請求，並將和應用邏輯不相關的決策程序導向其他Service Mesh框架下的服務。
舉例來說，開發者或許希望能夠依據公有或私有情境，分別管理處於不同環境下的微服務調用。這些管理的Policies對應用來說可能是不可見的，但是透過Sidecar的機制，它就能代替環境套用這些Policies到微服務的調用行為中。
閱讀更多 研華Advantech 的文章
