獨立伺服器怎麼組微服務

1. 如何完美使用微服務

容器

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

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

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

應用伺服器（Tomcat、nginx等）

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

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

2. 微服務架構是什麼

微服務架構是一項在雲中部署應用和服務的新技術。

大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。

微服務架構相關介紹：

微服務可以在「自己的程序」中運行，並通過「輕量級設備與HTTP型API進行溝通」。關鍵在於該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。

在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程的架構。

微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。

如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。

服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常復雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。

3. 怎麼用API網關構建微服務

由於這些問題的存在,客戶端與微服務直接通信很少是合理的。 使用API網關通常,一個更好的方法是使用所謂的API網關。API網關是一個伺服器,是系統的唯一...

4. 什麼是微服務架構主流的微服務如何實現

簡單地說，微服務架構就是以業務域或業務功能為邊界，將一個大而全的應用拆分為可以獨立開發，獨立部署，獨立測試，獨立運行的一組小的應用，並且使用輕量級，通用的機制在這組應用間進行通信。
主流的微服務包括：
1、SpringCloud

Spring Cloud , 來自Spring，具有Spring 社區的強大支撐，還有Netflix強大的後盾與技術輸出。Netflix作為一家成功實踐微服務架構的互聯網公司在幾年前就把幾乎整個微服務框架棧開源貢獻給了社區，這些框架開源的整套服務架構套件是Spring Cloud的核心。

- Eureka:服務注冊發現框架；

- Zuul:服務網關；

- Karyon：服務端框架；

- Ribbon：客戶端框架；

- Hystrix：服務容錯組件；

- Archaius：服務配置組件；

- Servo：Metrics組件；

- Blitz4j：日誌組件；

2、Dubbo

Dobbo是一個分布式服務框架，是阿里開放的微服務化治理框架，致力於提高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。其核心部分(官網)

- 遠程通訊: 提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式；

- 集群容錯: 提供基於介面方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持；

- 自動發現: 基於注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

Dubbo 也是採用全 Spring 配置方式，透明化接入應用，對應用沒有任何 API 侵入，只需用 Spring 載入 Dubbo的配置即可，Dubbo 基於 Spring 的 Schema 擴展進行載入。當然也支持官方不推薦的 API 調用方式。

3、lstio

lstio 作為用於微服務聚合層管理的新銳項目，是Google、IBM、Lyft（海外共享出行公司、Uber勁敵），首個共同聯合開源的項目，提供了統一的連接，安全，管理和監控微服務的方案。

目前首個測試版是針對Kubernetes環境的，社區宣稱在未來幾個月內會為虛擬機和Cloud Foundry 等其他環境增加支持。lstio將 流量管理添加到微服務中，並為增值功能（如安全性、監控、路由、連接管理和策略）創造了基礎。

- HTTP、gRPC 和 TCP 網路流量自動負載均衡；

- 提供了豐富的路由規則，實現細顆粒度的網路流量行為控制；

- 流量加密、服務件認證，以及強身份聲明；

- 全范圍（Fleet-wide）的策略執行；

- 深度遙測和報告。

5. 單伺服器適合微服務嗎

單伺服器是適合微服務的。
單服務架構是一直以來的傳統伺服器架構，它在一台伺服器上運行，然後由單一的程序提供服務。這種服務架構的好處，開發速度快，運行效率高。開始的時候你可以寫出最基礎的運行工作流程來，然後在以後的擴展中不斷的添加功能。
單服務架構比微服務架構是因為單服務架構沒有多餘的服務之間的通信。像微服務架構，裡面有很多微服務，它們之間的通信都是通過HTTP來進行的，如果用微服務系統的話，這是不可避免的。單服務架構則不需要這一部分額外的性能消耗。

6. http伺服器要拆分多個微服務嗎

需要。
要遵守服務拆分准則，繁多職責：扭轉一個類應該只有一個理由。如果一個類承載了多個職責，那麼，這個類就會非常不穩固。微服務架構下，應設計小、內聚、繁多職責的服務，那麼會大大提高服務的穩定性。
閉包準則：包中所有類，應該是同類變動的一個匯合。也就是說，如果須要對包做調整，須要調整的類、變數等，都應在這個包之內。需要變更，改變須要兩個耦合的包做調整，這是很大的危險。如果業務變更，只需調整同一個包下的類，那麼就能夠極大的改善，我的項目可維護性。微服務架構下，雷同起因須要扭轉的服務，放在一個組件內。需要變動的變更、部署，代價升高。能夠管制服務的數量。現實的狀況下，一個變更只會影響一個團隊。

7. 什麼是微服務

什麼是微服務

微服務架構的系統是一個分布式的系統，按業務進行劃分為獨立的服務單元，解決單體系統的不足，同時也滿足越來越復雜的業務需求。

一.單體架構

1.1什麼是單體架構

在軟體設計的時候經常提到和使用經典的3層模型，即表現層，業務邏輯層，數據訪問層。雖然在軟體設計中劃分了3層模型，但是對業務場景沒有劃分，一個典型的單體架構就是將所有的業務場景的表現層，業務邏輯層，數據訪問層放在一個工程中最終經過編譯，打包，部署在一台伺服器上。此時服務架構如圖：

1.2單體架構存在的不足

在小型應用的初期，訪問量小的時候這種架構的性價比還是比較高的，開發速度快，成本低，但是隨著業務的發展，邏輯越來越復雜，代碼量越來越大，代碼得可讀性和可維護性越來越低。用戶的增加，訪問量越來越多單體架構的應用並發能力十分有限。可能會有人想到將單體應用進行集群部署，並增加負載均衡伺服器，再來個緩存伺服器和文件伺服器，資料庫再搞個讀寫分離。這種架構如圖：

這種架構雖然有一定的並發能力，及應對一定復雜業務，但是依然沒有改變系統為單體架構的事實。大量的業務必然會有大量的代碼，代碼得可讀性和可維護性依然很差。如果面對海量的用戶，它的並發能力依然不夠。基於以上單體架構系統的不足，提出了微服務架構。

二.微服務

2.1什麼是微服務

說了這么多現在來看看到底什麼是微服務。微服務最初是由Martin Fowler提出來的他的理解如下：

微服務架構就是將單一程序開發成一個微服務，每個微服務運行在自己的進程中，並使用輕量級的機制通信，通常是HTTP RESTFUL API。這些服務圍繞業務能力來劃分，並通過自動化部署機制來獨立部署。這些服務可以使用不同的編程語言，不同資料庫，以保證最低限度的集中式管理。

1

總結起來微服務就是將一個單體架構的應用按業務劃分為一個個的獨立運行的程序即服務，它們之間通過HTTP協議進行通信（也可以採用消息隊列來通信，如RoocketMQ，Kafaka等），可以採用不同的編程語言，使用不同的存儲技術，自動化部署（如Jenkins）減少人為控制，降低出錯概率。服務數量越多，管理起來越復雜，因此採用集中化管理。例如Eureka，Zookeeper等都是比較常見的服務集中化管理框架。

2.2微服務的優勢

1）將復雜的業務拆分成多個小的業務，每個業務拆分成一個服務，將復雜的問題簡單化。利於分工，降低新人的學習成本。

2）微服務系統是分布式系統，業務與業務之間完全解耦，隨著業務的增加可以根據業務再拆分，具有極強的橫向擴展能力。面對搞並發的場景可以將服務集群化部署，加強系統負載能力。

3）服務間採用HTTP協議通信，服務與服務之間完全獨立。每個服務可以根據業務場景選取合適的編程語言和資料庫。

4）微服務每個服務都是獨立部署的，每個服務的修改和部署對其他服務沒有影響。

2.3微服務和SOA的關系

SOA即面向服務的架構，SOA是根據企業服務匯流排（ESB）模式來整合集成大量單一龐大的系統，微服務可以說是SOA的一種實現，將復雜的業務組件化。但它比ESB實現的SOA更加的輕便敏捷和簡單。