架構師必備技能：微服務架構

什麼是軟件架構?

軟件架構是一個包含各類組織的系統組織，這些組件包括 Web服務器, 應用服務器, 數據庫,存儲, 通信層), 它們彼此或和環境存在關係。

什麼是微服務架構?

微服務是指開發一個單個 小型的但有業務功能的服務，每一個服務都有本身的處理和輕量通信機制，能夠部署在單個或多個服務器上。

微服務也指一種種鬆耦合的、有必定的有界上下文的面向服務架構。也就是說，若是每一個服務都要同時修改，那麼它們就不是微服務，由於它們緊耦合在一塊兒；若是你須要掌握一個服務太多的上下文場景使用條件，那麼它就是一個有上下文邊界的服務

微服務優勢是什麼？

• 每一個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。
• 微服務可以被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
• 微服務是鬆耦合的，是有功能意義的服務，不管是在開發階段或部署階段都是獨立的。
• 微服務能使用不一樣的語言開發。
• 微服務容許容易且靈活的方式集成自動部署，經過持續集成工具，如Jenkins, Hudson, bamboo 。
• 一個團隊的新成員可以更快投入生產。
• 微服務易於被一個開發人員理解，修改和維護，這樣小團隊可以更關注本身的工做成果。無需經過合做才能體現價值。
• 微服務容許你利用融合最新技術。
• 微服務只是業務邏輯的代碼，不會和HTML,CSS 或其餘界面組件混合。
• 微服務可以即時被要求擴展。
• 微服務能部署中低端配置的服務器上。
• 易於和第三方集成。
• 每一個微服務都有本身的存儲能力，能夠有本身的數據庫。也能夠有統一數據庫。

微服務架構的缺點是什麼?

• 微服務架構可能帶來過多的操做。
• 須要DevOps技巧
• 可能雙倍的努力。
• 分佈式系統可能複雜難以管理。
• 由於分佈部署跟蹤問題難。
• 當服務數量增長，管理複雜性增長。

微服務適合哪一種狀況?

當你須要支持桌面 web 移動 智能電視 可穿戴時都是能夠的，甚至未來你可能不知道但須要支持的某種環境。

哪些公司或產品使用微服務架構?

大部分大型網站系統如Twitter, Netflix, Amazon 和 eBay都已經從傳統總體型架構monolithic architecture遷移到微服務架構

微服務之間是如何獨立通信的？

這依賴需求，經過使用HTTP/REST，數據格式使用JSON 或 Protobuf(Binary protocol)，通信協議是自由的。

爲何如今每一個人都在談論微服務？

自從SOA面試15年來，隨着RESTful web服務和JSON數據交換格式流行，簡單快速創建一個可鏈接的服務已經愈來愈方便了。

#開發方式影響 隨着持續交付概念推廣以及Docker容器普及，微服務將這兩種理念和技術結合起來，造成新的微服務+API + 平臺的開發模式，提出了容器化微服務的持續交付概念。

下圖傳統Monolithic的DevOps開發隊伍方式：

這種總體型架構要求產品隊伍橫跨產品管理 Dev開發 QA DBA 以及系統運營管理，而微服務架構引入之後，以下圖：

微服務促進了DevOps方式的重組，將一個大臃腫的總體產品開發隊伍切分爲根據不一樣微服務的劃分的產品隊伍，以及一個大的總體的平臺隊伍負責運營管理，二者之間經過API交互，作到了鬆耦合隔絕。

因爲Docker引入，不一樣的微服務可使用不一樣的技術架構，好比Node.js Java Ruby Python等等，這些單個的服務均可以獨立完成交付生命週期，以下：

微服務案例

Netflix的微服務架構以下，着重全球分發 高可擴展性和可用性：

Twitter的微服務架構，注重高效的可擴展的數據中心：

本文到此結束，喜歡的朋友記得點點贊和關注哈，感謝