微服務怎麼部署到同一台伺服器

Ⅰ 一般公司或者團隊是怎麼進行代碼開發並且部署到伺服器上的

廢話不多說，直接來乾的。這里介紹一套成熟的方案。

gitlab(代碼管理)+jenkins(持續集成)+k8s(服務管理)

其中涉及到的技術細節:dockerindockermakefile

gitlab使用介紹

gitlab是一款類似github的開源代碼管理軟體，可在公司內網，直接搭建一套私有代碼倉庫，適合團隊多人開發，具有完善的分支管理、角色管理、issue、里程碑等。是非常優秀的一款軟體。

jeknis使用介紹

這是一款開源持續集成軟體，說人話就是使用他可以自動化部署服務。其具有gitlab相關的插件，安裝後可直接對接gitlab，當gitlab發生push或者merge代碼事件，會通知jeknis去完成最新推送的代碼的鏡像構建和部署。

推薦上面說的兩款技術和jeknis混合使用。

1.dockerindocker技術。顧名思義就是docker裡面運行docker，簡單點直接用dockerfile在jeknis鏡像的基礎上安裝docker客戶端或者k8s客戶端。這樣我們孫搭薯在容器中就可以直接調用宿主機的docker命令或者k8s命令。這對我們使用jenkins執行部署腳本，通知k8s或者docker部署服務，非常方便。

2.makefile之所以介紹這款他，是因為其具有一個絕佳的功能，可以檢測文件內容是否發生變化，這樣對於微服務架構，其配合jenkins，無需指定什麼，就可以部署上發生文件變化的微服務。而不會影響到其他服枝碧務。

k8s使用介紹

這款當紅炸子雞?，相信大家耳聞已久。其實現了對docker的管理和編排。配合上共享存儲和其服務自動重則者啟機制，可以讓我們的服務無當機。

對於docker內部服務的暴露推薦ingress+service.

docker鏡像管理推薦harbor。

以上完整的自動化開發部署環境，有興趣的可以自行學習相關內容，進行搭建測試。

Ⅱ 如何把本地項目部署到伺服器上

把本地項目部署到伺服器上方法比較多，這里以javaee項目為例：

1、把項目打包成zip，

2、FTP上傳到生產伺服器tomcat的webapps目錄下解壓；

3、本地修改好的文件，

4、立即FTP上傳到生產伺服器對應的目錄；

5、生產伺服器安裝svn服務，在本地把修改過的文件commit，然後生產伺服器update。

(2)微服務怎麼部署到同一台伺服器擴展閱讀：

可以從這幾個方面來衡量伺服器是否達到了其設計目的；R：Reliability可靠性；A：Availability可用性；S：Scalability可擴展性；U：Usability易用性；M：Manageability可管理性，即伺服器的RASUM衡量標准。

1、可擴展性

伺服器必須具有一定的「可擴展性」，這是因為企業網路不可能長久不變，特別是在當今信息時代。如果伺服器沒有一定的可擴展性，當用戶一增多就不能勝任的話，一台價值幾萬，甚至幾十萬的伺服器在短時間內就要遭到淘汰，這是任何企業都無法承受的。為了保持可擴展性，通常需要在伺服器上具備一定的可擴展空間和冗餘件（如磁碟陣列架位、PCI和內存條插槽位等）。

可擴展性具體體現在硬碟是否可擴充，CPU是否可升級或擴展，系統是否支持WindowsNT、Linux或UNIX等多種可選主流操作系統等方面，只有這樣才能保持前期投資為後期充分利用。

2、易使用性

伺服器的功能相對於PC機來說復雜許多，不僅指其硬體配置，更多的是指其軟體系統配置。伺服器要實現如此多的功能，沒有全面的軟體支持是無法想像的。但是軟體系統一多，又可能造成伺服器的使用性能下降，管理人員無法有效操縱。所以許多伺服器廠商在進行伺服器的設計時，除了在伺服器的可用性、穩定性等方面要充分考慮外，還必須在伺服器的易使用性方面下足功夫。

伺服器的易使用性主要體現在伺服器是不是容易操作，用戶導航系統是不是完善，機箱設計是不是人性化，有沒有關鍵恢復功能，是否有操作系統備份，以及有沒有足夠的培訓支持等方面。

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

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

- 深度遙測和報告。

Ⅳ 如何快速搭建一個微服務架構

什麼是微服務？

微服務(Microservices Architecture)是一種架構風格，一個大型復雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。

微服務的概念源於2014年3月Martin Fowler所寫的文章「Microservices」 martinfowler.com/articles/mi…

單體架構(Monolithic Architecture )

企業級的應用一般都會面臨各種各樣的業務需求，而常見的方式是把大量功能堆積到同一個單體架構中去。比如：常見的ERP、CRM等系統都以單體架構的方式運行，同時由於提供了大量的業務功能，隨著功能的升級，整個研發、發布、定位問題，擴展，升級這樣一個「怪物」系統會變得越來越困難。

這種架構模式就是把應用整體打包部署，具體的樣式依賴本身應用採用的語言，如果採用java語言，自然你會打包成war包，部署在Tomcat或者Jetty這樣的應用伺服器上，如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應用以目錄層次的形式打包

上圖：單體架構

大部分企業通過SOA來解決上述問題，SOA的思路是把應用中相近的功能聚合到一起，以服務的形式提供出去。因此基於SOA架構的應用可以理解為一批服務的組合。SOA帶來的問題是，引入了大量的服務、消息格式定義和規范。

多數情況下，SOA的服務直接相互獨立，但是部署在同一個運行環境中（類似於一個Tomcat實例下，運行了很多web應用）。和單體架構類似，隨著業務功能的增多SOA的服務會變得越來越復雜，本質上看沒有因為使用SOA而變的更好。圖1，是一個包含多種服務的在線零售網站，所有的服務部署在一個運行環境中，是一個典型的單體架構。

單體架構的應用一般有以下特點：

微服務架構（Microservices Architecture）

微服務架構的核心思想是，一個應用是由多個小的、相互獨立的、微服務組成，這些服務運行在自己的進程中，開發和發布都沒有依賴。不同服務通過一些輕量級交互機制來通信，例如 RPC、HTTP 等，服務可獨立擴展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的編程語言來實現，由獨立的團隊來維護。簡單的來說，一個系統的不同模塊轉變成不同的服務！而且服務可以使用不同的技術加以實現！

上圖：微服務架構

微服務設計

那我們在微服務中應該怎樣設計呢。以下是微服務的設計指南：

微服務消息

在單體架構中，不同功能之間通信通過方法調用，或者跨語言通信。SOA降低了這種語言直接的耦合度，採用基於SOAP協議的web服務。這種web服務的功能和消息體定義都十分復雜，微服務需要更輕量的機制。

同步消息 REST

同步消息就是客戶端需要保持等待，直到伺服器返回應答。REST是微服務中默認的同步消息方式，它提供了基於HTTP協議和資源API風格的簡單消息格式，多數微服務都採用這種方式（每個功能代表了一個資源和對應的操作）

非同步消息 – AMQP, STOMP, MQTT

非同步消息就是客戶端不需要一直等待服務應答，有應到後會得到通知。某些微服務需要用到非同步消息，一般採用AMQP, STOMP, MQTT 這三種通訊協議

消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服務中另外一個很重要的因素。SOA的web服務一般採用文本消息，基於復雜的消息格式（SOAP）和消息定義（xsd）。微服務採用簡單的文本協議JSON和XML，基於HTTP的資源API風格。如果需要二進制，通過用到Thrift, ProtoBuf, Avro。

服務約定 – 定義介面 – Swagger, RAML, Thrift IDL

如果把功能實現為服務，並發布，需要定義一套約定。單體架構中，SOA採用WSDL，WSDL過於復雜並且和SOAP緊耦合，不適合微服務。

REST設計的微服務，通常採用Swagger和RAML定義約定。

對於不是基於REST設計的微服務，比如Thrift，通常採用IDL（Interface Definition Languages），比如Thrift IDL。

微服務集成 (服務間通信)

大部分微服務基於RPC、HTTP、JSON這樣的標准協議，集成不同標准和格式變的不再重要。另外一個選擇是採用輕量級的消息匯流排或者網關，有路由功能，沒有復雜的業務邏輯。下面就介紹幾種常見的架構方式。

點對點方式

點對點方式中，服務之間直接用。每個微服務都開放REST API，並且調用其它微服務的介面。

上圖：通過點對點方式通信

很明顯，在比較簡單的微服務應用場景下，這種方式還可行，隨著應用復雜度的提升，會變得越來越不可維護。這點有些類似SOA的ESB，盡量不採用點對點的集成方式。

API-網關方式

API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能個。通常，網關也是提供REST/HTTP的訪問API。服務端通過API-GW注冊和管理服務。

上圖：通過API-網關暴露微服務

所有的業務介面通過API網關暴露，是所有客戶端介面的唯一入口。微服務之間的通信也通過API網關。

採用網關方式有如下優勢：

目前，API網關方式應該是微服務架構中應用最廣泛的設計模式。

消息代理方式

微服務也可以集成在非同步的場景下，通過隊列和訂閱主題，實現消息的發布和訂閱。一個微服務可以是消息的發布者，把消息通過非同步的方式發送到隊列或者訂閱主題下。作為消費者的微服務可以從隊列或者主題共獲取消息。通過消息中間件把服務之間的直接調用解耦。

上圖：非同步通信方式

通常非同步的生產者/消費者模式，通過AMQP, STOMP, MQTT 等非同步消息通訊協議規范。

數據的去中心化

單體架構中，不同功能的服務模塊都把數據存儲在某個中心資料庫中。

每個微服務有自己私有的資料庫，其它微服務不能直接訪問。單體架構，用一個資料庫存儲所有數據

微服務方式，多個服務之間的設計相互獨立，數據也應該相互獨立（比如，某個微服務的資料庫結構定義方式改變，可能會中斷其它服務）。因此，每個微服務都應該有自己的資料庫。

每個微服務有自己私有的資料庫，其它微服務不能直接訪問。每個微服務有自己私有的資料庫，其它微服務不能直接訪問。

數據去中心話的核心要點：

數據的去中心化，進一步降低了微服務之間的耦合度，不同服務可以採用不同的資料庫技術（SQL、NoSQL等）。在復雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（網關）處理。

微服務架構的優點：

微服務架構的缺點：

微服務的一些想法在實踐上是好的，但當整體實現時也會呈現出其復雜性。

關於微服務架構的取捨