連年來，微處事架構及容器技能備受存眷，在種種文章、演講、博客中幾回表態，成為業界最熱門的話題。在時尚的詞匯和熱情滿滿的接頭背后，人們開始嚴肅的從頭思考互聯網時代處事的架構以及應用開拓、運維的要領。微處事以一種全新的架構設計模式，牽動了互聯網應用從設計到運維整個流程要領論的厘革。而以Docker為代表的容器技能則為微處事理念提供了匹配的實現機制，進而實質性的改變了新一代應用開拓和宣布的方法。

什么是微處事架構？

微處事架構（Microservices Architecture）是一種架構氣勢氣魄（Architectural Style）和設計模式，倡導將應用支解成一系列細小的處事，每個處事專注于單一業務成果，運行于獨立的歷程中，處事之間界線清晰，回收輕量級通信機制（如HTTP/REST）彼此相同、共同來實現完整的應用，滿意業務和用戶的需求。

微處事作為架構模式的厘革，其降生絕非偶爾。它是當傳統處事架構在互聯網時代遭遇挑戰時，人們對付架構模式，開拓和運維要領論的一種反思。所以，在深入探討微處事架構之前，我們先回首一下更為普遍的傳統處事架構。

傳統“單塊架構”：

在已往的10多年中，甚至是微處事日趨風行的當下，絕大大都應用回收的仍是我們更為熟悉的傳統架構，稱之為“單塊架構（Monolithic Architecture）”模式。此類架構系統凡是以技能分層，譬喻最常見的“分層架構”中的表示層、業務邏輯層、數據層。而業務邏輯則可按照更詳細的業務職責、成果舉辦模塊化，形成邏輯組件。這里需要提一下的是，“分層架構”固然有邏輯上的模塊和組件，但在物理陳設架構層面仍是一個“單塊”，凡是作為一個整體編譯、打包、陳設、運維。“單塊架構”即是從物理陳設角度，對付包羅“分層架構”在內的應用架構模式的一種界說。

“分層架構”是軟件架構體系中的經典模式，也是長時間來應用架構實際上的尺度。而單塊架構也有其必然優勢，浮現為：

便于開拓：大量常用的集成開拓情況（IDE）和編程框架（如Rails，Django）都是環繞傳統架構下單塊應用設計的。這些東西為開拓者提供了利便和熟悉的開拓、調試體驗。 便于測試：由于整個應用包括在一個歷程中，在常用東西的共同下應用可以很容易在開拓、測試情況中啟動。然后回收UI自動化東西（如Selenium）便可簡樸實現End-to-End測試。 便于陳設：大都編程語言和框架都有特定的應用打包名目。陳設只需將單一軟件包復制到運行情況。而這一進程也可通過現有東西實現自動化。

由于這些利益，在項目初期，單塊架構有必然的吸引力。開拓者可以通過東西、框架快速生成應用原型，而不必花大量精神在處事解析和漫衍式架構設計上。但跟著業務的擴張和成果的累積，原本簡樸的應用體積會迅速變大，此時單塊架構很難適應快速改觀的需求，由于架構層面的范圍性，這類應用謀面對多重挑戰。

開拓效率低：跟著應用巨大度的增加，越來越少開拓人員對應用能有全局性的深度領略。新成果開拓和缺陷修復難度呈幾許性增加。代碼修改的正確性無法保障。而復雜的代碼庫需要更復雜的開拓團隊來維護，無形中又增添了打點、相同和協調的本錢。別的，新插手的團隊成員需要耗費大量的時間和精神來熟悉一個巨大的代碼庫。 交付周期長：在單一歷程的單塊架構下，任何微小的竄改都需要從頭編譯、集成、測試和陳設整個應用。跟著應用體積的增大，交付流程和反饋周期城市相應變長，應用宣布的價錢也隨之增加。于是應用交付周期變緩，交付間隙積聚的代碼變換增加，從而對付下次交付發生更大的壓力，形成惡性輪回。 技能轉型難：單一歷程、單塊架構意味著中心化的技能選型。好比，應用的差異邏輯組建凡是需要回收相對統一的編程語言、框架和技能棧。這些在項目初始階段便已定型。之后，即即是應用中全新的邏輯組件，也很難回收差異的技能棧。而當應用到達必然局限后，全局化的技能棧更新謀面對很高的風險。所以，單塊架構應用一旦定型，就很難再享受行業技能改觀、成長所帶來的紅利。

由于這些布局性、系統性問題的存在，單塊架構下的應用越來越難適應互聯網時代快速改觀的市場需求。微處事即是從架構層面出發，敦促傳統應用開拓、運維方法的厘革，從而輔佐企業快速響應市場需求、快速迭代、快速交付，在互聯網時代保持競爭力。

微處事架構的優勢：