微服務架構(gòu)誕生以來，在各種演講、文章、書籍上所出現(xiàn)的頻率之高，足以看出它對軟件架構(gòu)領(lǐng)域帶來的巨大影響。經(jīng)過這兩年的快速普及，微服務的實踐已經(jīng)在越來越多的組織和企業(yè)內(nèi)部得以推廣和運用。

微服務架構(gòu)的演進，作為一種架構(gòu)模式，微服務將復雜系統(tǒng)切分為數(shù)十乃至上百個小服務，每個服務負責實現(xiàn)一個獨立的業(yè)務邏輯。這些小服務易于被小型的軟件工程師團隊所理解和修改，并帶來了語言和框架選擇靈活性，縮短應用開發(fā)上線時間，可根據(jù)不同的工作負載和資源要求對服務進行獨立縮擴容等優(yōu)勢。另一方面，當應用被拆分為多個微服務進程后，進程內(nèi)的方法調(diào)用變成了了進程間的遠程調(diào)用。引入了對大量服務的連接、管理和監(jiān)控的復雜性。讓我們來回顧一下微服務架構(gòu)的發(fā)展過程。在出現(xiàn)服務網(wǎng)格之前，我們最開始在微服務應用程序內(nèi)理服務之間的通訊邏輯，包括服務發(fā)現(xiàn)、熔斷、重試、超時、加密、限流等邏輯。

微服務的優(yōu)點：將應用程序分解為不同的更小的服務的好處是，它改進了模塊化，使應用程序更容易理解、開發(fā)、測試，并且更能抵御體系結(jié)構(gòu)的侵蝕。它還通過允許小型自治團隊開發(fā)、部署和部署來并行化開發(fā)。簡單來說，微服務架構(gòu)基本符合我們拆解問題的方式 -- 把一個復雜問題拆成多個簡單的問題，這個復雜問題就是在開發(fā)軟件過程中的復雜度問題，但微服務的拆解是基于業(yè)務模塊的。

總結(jié)一下：獨立性，這里的獨立性指的是各個服務的開發(fā)、測試、部署都相互獨立。比如：我們的用戶服務就可以拆分作為一個單獨的服務，而它的開發(fā)也不用依賴于其他服務。如果我們的用戶量大，我們可以很容易的對其進行負載。敏捷性，當一個新需求出現(xiàn)時，特別是在一個龐大的項目系統(tǒng)中，你得去考慮各方的問題，兼容性，影響度等等，而使用微服務則可以省掉很多這些廢時又燒腦的環(huán)節(jié)。實現(xiàn)更靈活，在以前的項目開發(fā)中，基本上一個大的項目都基于同一語言的技術(shù)架構(gòu)來開發(fā)，這樣的限制很大 。而使用微服務拆分后的各服務之間沒有這個限制，你只需要保證對外提供的接口是正?？捎玫木托小Ｖ劣谀闶鞘褂檬裁凑Z言、什么框架通通不用關(guān)心。

未來的幾年，相信會有更多的企業(yè)將目光聚焦在如何有效地將微服務落地這個核心問題上。微服務的概念看似淺顯易懂，但實際上卻與架構(gòu)演進、領(lǐng)域建模、持續(xù)交付及DevOps等多個維度的方法論與實踐密切相關(guān)。在一個分布式系統(tǒng)中，這部分邏輯比較復雜，為了為微服務應用提供一個穩(wěn)定、可靠的基礎(chǔ)設施層，避免大家重復造輪子，并減少犯錯的可能，一般會通過對這部分負責服務通訊的邏輯進行抽象和歸納，形成一個代碼庫供各個微服務應用程序使用?！拔⒎盏穆涞匦枰?jīng)過全面的考察和完善的試驗，并不是每個場景都適合使用微服務架構(gòu)，也不是每個企業(yè)都有能力或者精力去面對這些挑戰(zhàn)。

最后，和大家探討一下微服務拆分的通用策略：先從整體來分析業(yè)務的特性或者進行大模塊切分，比如基礎(chǔ)服務模塊、社區(qū)業(yè)務模塊、分發(fā)業(yè)務模塊等?？梢钥紤]先針對某些大模塊（而不是全部）進行切分，成功后再復用到其他模塊。遵循先少后多、先粗后細的原則，千萬不要試圖一次過拆分完成，那基本是不可能完成的任務。拆分時要考慮的因素至少包括：業(yè)務的獨立性及發(fā)展趨勢、微服務的研發(fā)維護及質(zhì)量流程、團隊特點及技術(shù)因素等。

中培偉業(yè)建立了完善的服務體系，即嚴格按照ISO9001國際質(zhì)量管理體系標準及咨詢服務業(yè)標準規(guī)范，建立了標準化的服務流程，對培訓、咨詢服務實施全過程質(zhì)量控制，關(guān)注顧客反饋，從而使客戶的需求得以實現(xiàn)。據(jù)該機構(gòu)相關(guān)老師介紹，機構(gòu)多年來立足實際，穩(wěn)定發(fā)展，每年分別舉辦微服務架構(gòu)設計公開課程和企業(yè)內(nèi)訓與咨詢100余場，并取得了不錯的市場反響。