微服務

㈠ 微服務有哪些特點

相比於傳統集中式的應用系統，微服務的優點：

• 每個服務獨立存在，所以可以單獨部署，不用每次發布某個功能都經歷一次全服務發布。

• 遵循單一功能原則，服務之間可以通過RESTFUL或者RPC調用，功能解藕

• 「細粒度」 的高可擴展性，每個服務都可以單獨擴展，單獨負載均衡

• 去中心化，盡可能地實現 「自服務」

• 有利於簡化單獨的開發測試以及部署，對開發團隊友好

微服務缺點：

• 服務的可用性和維護性高度依賴於服務治理，如果治理得不好將會是災難

• 某些服務可能造成性能瓶頸，某些服務的宕機可能導致很多服務受影響

• 服務配置繁瑣

㈡ 什麼是微服務

微服務架構是一項在雲中部署應用和服務的新技術。大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。
微服務可以在「自己的程序」中運行，並通過「輕量級設備與HTTP型API進行溝通」。關鍵在於該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程的架構。

㈢ 微服務,一個服務會影響整個系統嗎

摘要： 最近大家都在談微服務，隨著越來越多的在線業務需要提供更大並發的scale-up 和 scale out能力，微服務確實提供了比較好分布式服務的解決方案。

阿里雲高級解決方案架構師 楊旭

世界最大混合雲的總架構師，4年前，開始作為雙11阿里雲技術負責人，負責搭建全球最大的混合雲結構，把 「雙11」的電商業務和技術場景在阿里雲上實現，並保障這個混合雲在雙11當天能夠滿足全球客戶的購物需求。

正文：

最近大家都在談微服務，隨著越來越多的在線業務需要提供更大並發的scale-up 和 scale out能力，微服務確實提供了比較好分布式服務的解決方案。

微服務並不陌生，知道SOA其實也就很容易理解微服務，可以把微服務當做去除了ESB的SOA。ESB是SOA企業服務架構中的匯流排，而微服務是去中心化的分布式軟體架構，個人認為最大的設計區別在於設計初衷：

SOA是為了最大化的實現復雜系統代碼的可復用性
而微服務是為了最大限度的解耦，不同業務系統甚至可以是不同語言之間的通信
沒有最優的架構，只有最合適的架構，一切系統設計原則都要以解決業務問題為最終目標，脫離實際業務的技術情懷架構往往會給系統帶入大坑。所有問題的前提要搞清楚我們今天面臨的業務量有多大，增長走勢是什麼樣，而且解決高並發的過程，一定是一個循序漸進逐步的過程。

網上的一張圖很經典，總結的非常好：

整個系統進化分為三個階段：

x軸，水平擴展階段，通過負載均衡伺服器不斷的橫向擴充應用伺服器，水平擴展最重要的問題是需要注意不用伺服器之間的如何保持session和會話同步，不能讓用戶在不通伺服器之間切換時有感知應用擴展後自然遇到的問題就是DB的瓶頸：連接數，iops等。

z軸，就是對資料庫的拆分，難度上了一個台階，Sharding的基本思想就要把一個資料庫如何進行切分，可以分為水平切分和垂直切分，水平切分相對簡單，一主多從，多主都可以，根據業務的需要，多主切分設計時需要注意主鍵的關系，解決多寫在進行數據同步時候的沖突問題，垂直拆分更加復雜，一般都會涉及到架構邏輯的改造，需要引入中間件，來進行數據源的管理，垂直拆分時把關系緊密（比如同一模塊）的表切分出來放在一個庫上，或者通過hash進行拆分，從而將原有資料庫切分成類似矩陣一樣可以無限擴充的隊列。

y軸擴展，最後就是功能分解了，也就是我們講的微服務切分。微服務拆分將巨型應用按照功能模塊分解為一組組不同的服務，淘寶的系統當年也經歷了這樣的過程，通過五彩石項目從單一的war包拆分成了今天的大家看到買家，賣家中心，交易等系統。

引入微服務前你要知道的兩三事：

1、成本升高，引入微服務架構，需要對原來單一系統進行拆分，1到100以後多服務的部署會帶來成本的升高

2、解決分布式事務一致性問題

以前單一的系統好處很多，一條sql解決完成所有業務邏輯，微服務做完一件事情需要涉及多系統調用，系統間網路的不確定性給結果帶來很多不確定性，如今天淘寶的系統，完成一次交易下單需要在上百個系統之間調用，如何保證系統的可靠性，以及核心數據如錢的最終一致性是設計之初就要想明白的，這里大多都要藉助中間件來實現。

3、微服務的邏輯設計原則

隨著不斷拆分微服務，以及業務的迭代發展，系統之間極有可能出現混亂調用，所以微服務的頂層設計顯得尤為重要，架構師需要搞清楚微服務的架構模型。那核心的設計思想就在於如何進行服務的分層，以及服務的重用，通過分層將服務進行分配，上層服務包裝下層服務，下層服務負責原子性的操作，上層服務對下層服務進行業務性的組合編排，一定要理解業務，微服務拆分不是簡單的系統組合，再說一遍一定要理解業務，否則上層服務一定會出現大量的交叉調用，系統復雜度會指數級上升，好的微服務架構師一定是業務架構師，基於業務的建瓴，微服務設計三部曲，遵循自下而上的設計原則：

原子服務

首先確認最基本業務最維度的原子服務，原子服務定義就是大家都會最大化重用的功能，需要在應用內的閉環操作，沒有任何跨其他服務的分支邏輯，杜絕對其他服務的調用，有自己獨立的數據存儲，作為最底層服務抽象存在，以淘寶為例，賣家數據，賣家數據，訂單數據就屬於最基本的原子服務。

服務組合

在業務場景下，一個功能都需要跨越多個原子服務來完成一個動作。組合服務就是將業務邏輯抽象拆成獨立自主的域，域之間需要保持隔離，服務組合會使用到多個原子服務來完成業務邏輯，如淘寶的交易平台會調用用戶，商品，庫存等系統。

業務編排

最外層就是面向用戶的業務流程，一個產品化的商業流程需要對組合服務進行邏輯編排來完成最終的業務結果，這個編排服務可以完全是自動化的，通過工作流引擎進行組合自動化來完成特定SOP定義，這對企業應用的自動化流程改進也很有意義。如淘寶類目的雙十一活動，通過對不通服務組合進行重用實現不通的營銷活動邏輯。

4、運維管理的復雜度提升

微服務讓應用數量增加很多，鏈路的集成、測試、部署都成為新的挑戰，以前一個war包解決的問題，需要通過多應用發布來完成，發布時服務之間的依賴影響，會導致功能不可用，測試階段的依賴性可能會讓用例跑不下去，這些都會是需要新考慮的問題，需要有平台化的工具來支撐，目前阿里通過aone產品來保證從日常到預發到線上的持續集成交付。

㈣ 微服務的優點

微服務是指提供單個業務功能的服務，從技術角度看就是一種小而獨立的處理過程，類似流程概念，能夠自行單獨啟動或銷毀，擁有自己獨立的資料庫。

一個復雜軟體架構是由很多這樣小而獨立運行（有自己的埠）微服務組成，這些獨立處理組件之間通訊是通過與語言無關的API進行，簡單協議有同步性質的RMI/RPC和 RESTful Web Services，非同步的消息推送和Reactive方式。

這些模塊化的方式能夠使得公司將項目分解分散到多個開發團隊，跨不同業務部門，提供非常充分的靈活性，幫助提高項目的生命周期，加快項目開發完成效率。

每個微服務組件都有自己分配的存儲 內存和CPU資源，這就使得硬體利用更加易於優化和跟蹤，特別是在基於雲的Pass環境，開發團隊可以使用他們喜歡的技術，任何語言都可以，只要確保微服務之間是可交互的，能夠最終組合起最後的應用。

當管理復雜性會因為採取微服務架構而降低，通常更新其中一個微服務組件不會引起連鎖反應，因為微服務之間是松耦合的。

目前使用微服務的企業有：Netflix Twitter Amazon Web Services (AWS), Google, eBay等。

因為有很多應用和服務部署在基於雲主機的環境中，微服務架構將會嚴重依賴容器技術，容器隔離了微服務處理過程，將一個應用切分為一個個小的實例，這些容器中的小實例有自己的埠和虛擬化環境。

廣泛使用的容器技術是Docker, 一種基於Linux的開源實現，由很多軟體公司支持如 Canonical, Red Hat,和Parallels. PaaS服務支持包括Google App Engine, Red Hat Open Shift,和VMware的 Cloud Foundry,。

㈤ 微服務都是用在什麼地方能否舉例說明一下

隨著移動互聯網的發展和應用雲化的普及，微服務已經成為企業應用服務化架構最流行的設計理念。以微服務、容器、DevOps等為支撐的雲原生設計理念，緩解了隨著新需求的不斷增加，大型單體式應用變更越來越困難的現狀，與移動互聯網時代下對企業IT架構高效穩定、敏捷響應的要求之間的矛盾。
「Nebulogy納比雲」提供完整的微服務實施平台及賦能工具，加速微服務應用開發和DevOps持續交付，為雲應用的構建和運行支撐提供有力的支持。微服務實施方案

㈥ 「微服務」是什麼意思

微服務是對於微信公眾平台帳號提供的輔助管理平台，強化了微信公眾號的互動營銷推廣與客戶關系維護功能。

㈦ 什麼是微服務框架

不太確定你說的什麼是微服務框架，好像來說就是一個小程序的意思吧。

㈧ 微服務優點

微服務是一種軟體架構風格，它是以專注於單一責任與功能的小型功能區塊為基礎，利用模組化的方式組合出復雜的大型應用程序，各功能區塊使用與語言無關的 API（例如 REST）集相互通訊，且每個服務可以被單獨部署，在微服務軟體架構風格概念被提出來的初期，它具備以下三個核心特點：

1. 微服務為大型系統而生。 通常我們在系統架構設計上面臨的問題都與系統的大小相關，隨著業務的快速增長，會帶來系統流量壓力和復雜度的上升，系統的可維護性和可擴展性成為架構設計的主要考慮因素，微服務架構設計理念通過小而美的業務拆分，通過分而自治來實現復雜系統的優雅設計實現。

2. 微服務架構是面向結果的。 微服務架構設計風格的產生並非是出於學術或為標准而標準的設計，而是在軟體架構設計領域不斷演進過程中，面對實際工業界所遇到問題，而出現的面向解決實際問題的架構設計風格。

3. 專注於服務的可替代性來設計。 微服務架構設計風格核心要解決的問題之一便是如何便利地在大型系統中進行系統組件的維護和替換，且不影響整體系統穩定性。微服務帶來的好處
獨立的可擴展性，每個微服務都可以獨立進行橫向或縱向擴展，根據業務實際增長情況來進行快速擴展；

獨立的可升級性，每個微服務都可以獨立進行服務升級、更新，不用依賴於其它服務，結合持續集成工具可以進行持續發布，開發人員就可以獨立快速完成服務升級發布流程；

易維護性，每個微服務的代碼均只專注於完成該單個業務范疇的事情，因此微服務項目代碼數量將減少至IDE可以快速載入的大小，這樣可以提高了代碼的可讀性，進而可以提高研發人員的生產效率；

語言無關性，研發人員可以選用自己最為熟悉的語言和框架來完成他們的微服務項目（當然，一般根據每個公司的實際技術棧需要來了），這樣在面對新技術或新框架的選用時，微服務能夠更好地進行快速響應；

故障和資源的隔離性，在系統中出現不好的資源操作行為時，例如內存泄露、資料庫連接未關閉等情況，將僅僅只會影響單個微服務；

優化跨團隊溝通，如果要完全實踐微服務架構設計風格，研發團隊勢必會按照新的原則來進行劃分，由之前的按照技能、職能劃分的方式變為按照業務（單個微服務）來進行劃分，如此這般團隊里將有各個方向技能的研發人員，溝通效率上來說要優於之前按照技能進行劃分的組織架構；

原生基於「雲」的系統架構設計，基於微服務架構設計風格，我們能構建出來原生對於「雲」具備超高友好度的系統，與常用容器工具如Docker能夠很方便地結合，構建持續發布系統與IaaS、PaaS平台對接，使其能夠方便的部署於各類「雲」上，如公用雲、私有雲以及混合雲。

㈨ SOA和微服務架構的區別

SOA與微服務架構，在架構劃分、技術平台選擇等方面，均存在一定的區別。

一、架構劃分不同

1、SOA強調按水平架構劃分為：前、後端、資料庫、測試等；

2、微服務強調按垂直架構劃分，按業務能力劃分，每個服務完成一種特定的功能，服務即產品。

二、技術平台選擇不同

1、SOA應用傾向於使用統一的技術平台來解決所有問題；

2、微服務可以針對不同業務特徵選擇不同技術平台，去中心統一化，發揮各種技術平台的特長。

三、系統間邊界處理機制不同

1、SOA架構強調的是異構系統之間的通信和解耦合；（一種粗粒度、松耦合的服務架構）；

2、微服務架構強調的是系統按業務邊界做細粒度的拆分和部署。

四、主要目標不同

1、SOA架構，主要目標是確保應用能夠交互操作；

2、微服務架構，主要目標是實現新功能、並可以快速拓展開發團隊。

參考資料

網路-SOA

網路-微服務架構