微服務需要多少機器

Ⅰ 微服務為什麼一定要用Docker

早在2013年的時候，docker就已經發行，然而那會還是很少人了解docker。一直到2014年，Martin Fowler提出了微服務的概念，兩個不相乾的技術終於走在了一起，創造了今天的輝煌！

現在:用上了docker容器後，將Docker可以將我們的應用程序打包封裝到一個容器中，該容器包含了應用程序的代碼、運行環境、依賴庫、配置文件等必需的資源。容器之間達到進程級別的隔離，在容器中的操作，不會影響道宿主機和其他容器，這樣就不會出現應用之間相互影響的情形！

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

摘要： 最近大家都在談微服務，隨著越來越多的在線業務需要提供更大並發的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產品來保證從日常到預發到線上的持續集成交付。

Ⅲ spring cloud 微服務 需要service層嗎

需要的
Spring IO platform:用於系統部署，是可集成的，構建現代化應用的版本平台，具體來說當你使用maven dependency引入spring jar包時它就在工作了。
Spring Boot:旨在簡化創建產品級的 Spring 應用和服務，簡化了配置文件，使用嵌入式web伺服器，含有諸多開箱即用微服務功能，可以和spring cloud聯合部署。
Spring Framework:即通常所說的spring 框架，是一個開源的Java/Java EE全功能棧應用程序框架，其它spring項目如spring boot也依賴於此框架。
Spring Cloud：微服務工具包，為開發者提供了在分布式系統的配置管理、服務發現、斷路器、智能路由、微代理、控制匯流排等開發工具包。
Spring XD：是一種運行時環境（伺服器軟體，非開發框架），組合spring技術，如spring batch、spring boot、spring data，採集大數據並處理。
Spring Data：是一個數據訪問及操作的工具包，封裝了很多種數據及資料庫的訪問相關技術，包括：jdbc、Redis、MongoDB、Neo4j等。
Spring Batch：批處理框架，或說是批量任務執行管理器，功能包括任務調度、日誌記錄/跟蹤等。
Spring Security：是一個能夠為基於Spring的企業應用系統提供聲明式的安全訪問控制解決方案的安全框架。
Spring Integration：面向企業應用集成（EAI/ESB）的編程框架，支持的通信方式包括HTTP、FTP、TCP/UDP、JMS、RabbitMQ、Email等。
Spring Social：一組工具包，一組連接社交服務API，如Twitter、Facebook、LinkedIn、GitHub等，有幾十個。
Spring AMQP：消息隊列操作的工具包，主要是封裝了RabbitMQ的操作。
Spring HATEOAS：是一個用於支持實現超文本驅動的 REST Web 服務的開發庫。
Spring Mobile：是Spring MVC的擴展，用來簡化手機上的Web應用開發。
Spring for Android：是Spring框架的一個擴展，其主要目的在乎簡化Android本地應用的開發，提供RestTemplate來訪問Rest服務。
Spring Web Flow：目標是成為管理Web應用頁面流程的最佳方案，將頁面跳轉流程單獨管理，並可配置。
Spring LDAP：是一個用於操作LDAP的Java工具包，基於Spring的JdbcTemplate模式，簡化LDAP訪問。
Spring Session：session管理的開發工具包，讓你可以把session保存到redis等，進行集群化session管理。
Spring Web Services：是基於Spring的Web服務框架，提供SOAP服務開發，允許通過多種方式創建Web服務。
Spring Shell：提供互動式的Shell可讓你使用簡單的基於Spring的編程模型來開發命令，比如Spring Roo命令。
Spring Roo：是一種Spring開發的輔助工具，使用命令行操作來生成自動化項目，操作非常類似於Rails。
Spring Scala：為Scala語言編程提供的spring框架的封裝（新的編程語言，Java平台的Scala於2003年底/2004年初發布）。
Spring BlazeDS Integration：一個開發RIA工具包，可以集成Adobe Flex、BlazeDS、Spring以及Java技術創建RIA。
Spring Loaded：用於實現java程序和web應用的熱部署的開源工具。
Spring REST Shell：可以調用Rest服務的命令行工具，敲命令行操作Rest服務。

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

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

Ⅳ 什麼是微服務

微（micro）就是指體積小，服務（service）區別於系統，服務於一個或者一組相對較小且獨立的專功能單元，是用戶可以感知屬最小功能集。微服務是一種分布式系統解決方案架構。將單個應用程序作為一組小型服務，每個服務程序都在自己的進程中運行，並與輕量級機制進行通信。服務圍繞業務功能構建。可以通過全自動部署機器獨立部署。可以用不同的編程語言編寫，使用不同的數據存儲技術，並盡量不採用集中式管理。我在黑馬程序員社區學到的，社區有很多學習視頻，路線圖什麼的，感覺對學習編程的小夥伴很有用，想學習的可以看一下。謝謝你對我們的支持，希望我的回答能有所作用，歡迎追問，再次表示感謝！

Ⅵ 在微服務架構中，我們還需要ESB嗎

不需要，過去採用ESB（企業服務匯流排）經常會發現到最後系統變得異常臃腫，不利於治理。微服務架構相比ESB可以說是在正確的方向上前進了一大步，不過微服務架構也會面臨復雜性問題，主要集中在服務之間的通信，這也就是為什麼大家開始關注service mesh這種對服務透明的新型微服務架構，來解決服務發現、負載均衡、路由、流量控制、通信可靠性、彈性、安全、監控/日誌方面的問題。——答案來源好雨雲博客

Ⅶ 為什麼微服務需要API網關

1.防止內部關注暴露給外部客戶端
API網關將外部公共API與內部微服務API分開，允許添加微服務和更改邊界。 其結果是能夠在不對外部綁定客戶端產生負面影響的情況下重構和適當大小的微服務。 它還通過為您的所有微服務提供單一入口點，對客戶端隱藏了服務發現和版本控制詳細信息。

2.為您的微服務添加額外的安全層
API網關通過提供一個額外的保護層來防止惡意攻擊，例如SQL注入，XML解析器漏洞和拒絕服務（DoS）攻擊。

3.支持混合通信協議
雖然面向外部的API通常提供基於HTTP或REST的API，但是內部微服務可以從使用不同的通信協議中受益。 協議可能包括的Protobuf或AMQP ，或者用SOAP，JSON-RPC或XML-RPC系統集成。 API網關可以在這些不同的協議之上提供外部的，統一的基於REST的API，允許團隊選擇最適合內部架構的API。

4.降低微服務復雜性
如果微服務具有共同的關注點，例如使用API令牌的授權，訪問控制實施和速率限制。 每個這些關注可以通過要求每個服務都實現它們，但這為微服務的開發增加更多的時間成本。 API網關將從您的代碼中刪除這些問題，允許您的微服務關注手頭的任務。

5.微服務模擬和虛擬化
通過將微服務API與外部API分離，您可以模擬或虛擬化服務，以驗證設計要求或協助集成測試。

Ⅷ SpringCloud項目，每個微服務配置一個數據源好還是微服務里配置多個數據源好

我們這邊是所有服務統一使用同一數據源，資料庫連接信息配置回到環境變數之中，所有答微服務統一讀取這組環境變數。

你要是設置成多數據源，未來系統故障時查找數據方面的問題多麻煩啊。
對於業務需要，真的是有比如兩個數據源的，假設是主數據源A和輔數據源B，那麼可以基於輔數據源B搭建一個微服務，暴露API，由主數據源服務在需要時調用輔數據源的服務的API就好。
不過如果輔數據源可能只有一個最簡單的查詢，沒有更多操作了，你在主數據源服務中直接配置多數據源也沒問題。
我仔細想了一下，似乎還是各個數據源單獨起一個自己的服務這樣更有「分布式微服務」的樣子呢。

Ⅸ 如何完美使用微服務

容器

同時處理很多項微服務可能會十分復雜，因為每個微服務的編程語言可專能不一樣，可能需要不同的屬應用伺服器（最好是輕量級的伺服器），也可能使用不同的庫。但如果我們將每個服務都當做容器來包裝，那麼這些問題都會迎刃而解。我們只需要運行容器（例如用Docker運行容器），其他需要的東西統統都在容器內部了。

容器本身是自給自足的，其內部包含我們需要的所有東西（除了內核kernel），此外各個容器單獨運行並不可改變。而自給自足則意味著容器通常具有以下幾個部分。

運行時間庫（運行應用時所需的JDK、Python或其他庫）

應用伺服器（Tomcat、nginx等）

資料庫（最好是輕量級的）

工件（JAR、WAR、靜態文件等）

Ⅹ PWorld微服務來了，配置怎麼辦

微服務的概念產生是順應這樣的需求：為了開發出速度更快、更有彈性且用戶體驗更佳的應用。這個概念等同於具有可擴展性的自動化系統，在簡單的商業化架構上運行軟體。由於容器所提供的經濟效率，在2016年微服務將是一大主題。

應用快速開發的需求影響到了全部公司，以及如何看待歷來業務安排的方式。來自微服務的新實踐代表著需要小型團隊以對於公司來說陌生的方式——自上而下進行迭代。這意味著企業運作的方式將獲得徹底的改變。

現在在針對應用架構與微服務的新思考方面，容器生態系統逐漸成為核心主題。根據Battery Ventures技術人員Adrian Cockcroft的說法：關於微服務有一些基本的原則需要思考。首先，如今構建軟體的價格更為低廉，容器的出現降低了成本。Docker被所有人納入藍圖——從軟體供應商到終端用戶，所有人都在嘗試找出容器的用法，因為用它就能加快軟體的交付節奏。不過這也代表著要安裝的系統是應用級別的，也就是說在應用的開發、部署與管理方面出現了不同的需求。

Adrian Cockcroft在面向對象軟體架構大會上關於微服務的演講，以卡通形式呈現，作者是Remarker

舉個例子，對於要處理服務與堆棧范圍增長的公司來說，監控比以往更加重要。要想解決問題，必須對數據日誌進行分析，而這些日誌很可能橫跨臨時節點與多項服務。由於需要細化監控與加強工具，從業人員能更好地掌握這些構建模塊對於應用所依賴的許多潛在微服務的影響。

那麼起作用的是什麼呢？從公司與API開始：基於微服務的產品團隊與另一個基於終端的平台團隊之間靠API連接，通過API調用以及企業基礎架構持續作出相應的回應來生效。

微服務被定義為特定背景下松耦合、面向服務的架構，允許在無需理解其他部件運作原理的情況下進行更新。整個服務是跨公司構建的，但所有權卻在同一個地方。微服務架構提供了更多系統間的點對點調用。消息形式必須靈活，所有部件在無論哪個版本中都能運作。這意味著在構建微服務架構時，我們需要一些工具來配置、探索、輸送流量、觀察與構建系統。

IBM傑出的工程師兼IBM雲計算中心的CTO Andrew Hately作出了類比：15年前人們可能需要每周查看一下自己的銀行余額，而互聯網允許人們實時查看余額甚至做出進一步操作，也許隨著智能手機的發展，很多事情都發生的改變。如今，人們可以即時訪問自己的賬戶收支信息。這種速度與即時性代表著：在過去的5-10年內，企業提供服務的發展速度必須跟得上社交網路與搜索公司發展的速度。

公司必須處理員工、消費者、系統與所有可能組合之間的持續互動——就像Hately所說的完全互聯與持續可用。這意味著企業流程需要重建，需要將所有東西連接起來。如果公司不進行這方面的嘗試，也無法提供相應功能的話，很快就會面臨收入減少甚至出局的局面。

Hately表示：「工具非常關鍵。」 有數百家網站不支持代碼，收到反饋後，在下一組測試用例中消費者就能使用它了。這種嚴格的開發過程提供了一種企業工作方式，也為微服務發展提供了思考方式。DevOps中的ops也會執行這樣的工作。如果你有一小段代碼並為其定義指標的話，就能細分出哪些會成功，哪些會失敗。

IBM通過為消費者及內部團隊構建反饋通道與成功標准，在敏捷、DevOps、精益生產與其他迭代進程中結合最佳實踐，創建了名為IBM Bluemix Garage Method方法的企業方法論。IBM Bluemix Garage Method方法將企業解決方案的可靠性及可測試性與最新開放社區在規模質量上的最佳實踐結合起來，持續創新、創建持續交付渠道並在雲平台上進行部署。這種方法很有價值，向所有人開放資源能夠提高個人、團隊與全公司的DevOps技能，以及管理與監控能力。