⑴ 微服務 多個為服務之間怎麼協作
服務與服務之間的通訊現在大部分是用的Http+Rest的方式來處理的,但是當服務個數的增加真的不知道為出現什麼問題,現在好像也沒有哪個公司的量級到了這個出現問題的程度,相反,我覺得是用SOA的方式來管理服務與服務之間的通訊未必不是一件壞事,畢竟好用才是王道.針對這個問題我也有一篇blog說明,你可以看看: 微服務之間介面調用的一種新架構思路 歡迎拍磚 補充:這個架構是面向連接的,不是面向數據的
⑵ 多個.so文件使用微服務獨立部署，但是部署的時候埠又不一樣，調用API時又要統一ip和埠，應該怎麼辦
方法/步驟
創建一個解決方案，添加3個類庫項目，1個ASP.NET MVC4項目，如下圖所示：
11
通過注冊區域的方式，不同的程序開發人員就能獨立的開發後端的服務，然後把編譯好的dll丟到網站的bin目錄中，只要在網站中按約定建立好視圖，這樣後端即實現了服務獨立，又能滿足集中部署的需求。
⑶ 如何在開發時部署和運行前後端分離的JavaWe
在開發中大型的JavaEE項目時，前後端分離的框架逐漸成為業界的主流，傳統的單機部署前後端在同一個項目中的工程項目越來越少。這類JavaWeb項目的後端通常都採用微服務的架構，後端會被分解為諸多個小項目，然後使用bbo+zookeeper或者springCloud來構建微服務，前端則會是一個單獨的項目，前台的請求通過微服務來調用。但是，不同與傳統的web項目，這類前後端分離的項目如何在開發中部署和運行呢？
當前後端分離時，後端項目一定會被載入到tomcat的webapp目錄下面，但是前端的資源院該如何被訪問到呢？這里以tomcat這個中間件為例，探討在開發這類項目的時候，如何讓前後端分離的項目部署並且運行起來，即後端項目部署在tomcat之後如何在運行時訪問靜態資源（非上線部署）。
主要有兩種方案：1.在本地通過Nginx來處理這些靜態資源。2、將靜態資源統一放入一個javaweb應用中，並將自動生成的war包隨後端項目一期丟入tomcat。下面詳細介紹
一、使用Nginx來訪問靜態資源。
在本地安裝nginx並且修改nginx.conf，修改相關配置，將web訪問的埠的資源進行更改，配置如下：
server { listen 80; server_name localhost; charset utf-8; #access_log logs/host.access.log main;
location / { proxy_pass http://tomcat_pool; proxy_redirect off;
proxy_set_header HOST $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
location ~ .*.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css|woff|woff2|ttf|eot|map)$ {
root D:Workspacesesop-html; index index.html;
}
listen對象改為你本地的tomcat訪問埠，最下面location中的root改為你前端項目中靜態資源的位置，這樣就可以實現只部署後端的項目就能訪問前端的頁面了。
二、將前端項目轉換為動態的web項目，隨後端項目一起丟入tomcat
這個方案省去了在本地安裝和配置nginx，但是也只適用於開發階段項目的部署運行和調試，真正在生產環境通常前後端項目會部署在不同的伺服器。
如果是Intellij Idea,在導入前端項目之後，右鍵項目 add framework support --> web application，這時將會把前端項目轉換為一個javaweb項目，然後將靜態資源放在生成的web目錄下即可。
如果是eclipse，可以新建一個javaweb項目然後將靜態資源放入web或者webcontent目錄下，或者直接先導入前端項目，然後通過 project facts 將項目轉換為dynamic web項目並勾選 js等相關配置。
然後，運行項目時把後端的war包和前端的war包一同添加到 deployment中運行即可。
⑷ 什麼是微服務架構主流的微服務如何實現
簡單地說，微服務架構就是以業務域或業務功能為邊界，將一個大而全的應用拆分為可以獨立開發，獨立部署，獨立測試，獨立運行的一組小的應用，並且使用輕量級，通用的機制在這組應用間進行通信。
主流的微服務包括：
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）的策略執行；
- 深度遙測和報告。
⑸ 如何設計實現真正的響應式微服務系統
一、清晰輕量的產品邏輯
奧卡姆剃須刀法則同樣在產品架構設計中適用，越簡單的架構越有利於產品的生長。清晰輕量的產品邏輯，會減少用戶的負擔感，從而提高交互上的效率和愉悅感。
分析Material Design，會發現Google歸納了兩類復雜內容信息的層級關系，分別是Card和Tile（List
以及其他相似定義屬於同類的內容信息層級），其他定義多用於UI結構及細節。其中，Google定義Card是一種多功能信息的聚合入口，信息層級應較
高，體現在Z軸應高於其他信息，視覺上有陰影表現並加以圓角處理。而tile（或同類信息列表）則是（同類或相關）信息的模塊展現，信息層級應較低，體現
在Z軸應略低於其他信息，視覺上應無陰影表現不加圓角處理。其結果是從視覺層面讓產品對象更高效、更簡單，同時也更具物理世界的「真實感」。
最近接手的項目是Gekec.com的全站改版。Gekec（革客）是Geek和Maker交集，喜歡革新，喜歡技術范兒、新潮的科技消費品，喜歡
自己動手創造產品，Gekec.com也就是這類人的聚集地，整個產品囊括電商、資訊（或h5宣傳）、拆機、以及社區討論等各種功能，改版前邏輯復雜，功
能繁多。改版開始之初，筆者了解到革客群體時，便認為理性加濃重Geek味道的Google風格或許是最適合Gekec.com的視覺體系，然而復雜的產
品邏輯不能給用戶帶來高效的交互體驗和愉悅的使用感受，視覺上也並不能很好的通過Material
Design推演並且變化，所以梳理出清晰、輕量且方便視覺統一的產品邏輯成為第一任務。
Gekec.com的產品全功能在此並不贅述，Proct Feature全部為達成宜家式的體驗式設計，經過梳理可以歸納成三層，首層為體驗層（多入口的首頁封面）、第二層為貨架層（包括商城模塊、拆機模塊、體驗模塊）、第三層為詳細、操作層；
如上圖，輕量的產品結構即可方便設計的推演。例如其中第一層可以通過H5靈活排版做產品全方位體驗，第二層與第三層的關系即可利用Material
Card和Tile表現。Card表達了全部信息的聚合和入口，tile則表現同類信息的羅列。從card跳轉到最終頁應有一種卡片展開的體驗。
二、適宜UI推演的響應辦法
在產品邏輯清晰簡潔的基礎上，一套適宜Material Design變化的全尺寸響應辦法就成為復雜響應式網頁設計的核心內容，響應辦法能夠直接決定功能模塊的響應邏輯以及UI的變化。實際操作中，響應辦法的確定主要就是確定柵格和佔比。
1）柵格
網頁柵格系統是從平面柵格系統中發展而來。對於網頁設計來說，柵格系統的使用，不僅可以讓網頁的信息呈現更加美觀易讀，更具可用性。而且，對於前端
開發來說，網頁將更加的靈活與規范。柵格系統的具體含義以及使用方法在此不再贅述，感興趣的朋友可以參考淘寶UED的一些文章：
網頁柵格系統研究（1）：960的秘密
網頁柵格系統研究（2）：蛋糕的切法
網頁柵格系統研究（3）：粒度問題
網頁柵格系統研究（4）：技術實現
在Gekec.com的項目中，經歷產品功能模塊的梳理，筆者使用了12柵格系統，目的是能夠滿足2、3、4、6的頁面等分。註：具體柵格系統的建立應因產品和設計所決定，柵格系統並不是萬能的，而確定的柵格系統可以為整個響應式設計做規范性參考。
2）佔比
A.佔比
如上文說，12柵格約束網頁的內容區，而網頁的內容往往並不佔據屏幕的全部寬度，而是在兩側留有間隙，營造空間感。由於屏幕的限制，這種空間感在移動端設備顯得更加重要，如圖，然而強加固定的margin pixel會使得12柵格佔比不定，難以控制設計效果。
所以佔比應是12柵格寬度對應屏幕的比值，即：
12柵格寬度X佔比=屏幕寬（臨界點）
優秀而巧妙的佔比確定可以讓網頁設計呈現在各個主流屏幕上均是100%像素。
這里簡單解釋一下，若一個200px寬的元素在1200px寬的屏幕上，其佔比為16.67%，同樣的邏輯，到1024px的屏幕上這個佔比
16.67%的元素即占據了170.67px，這樣的情況下，某一個物理像素無法佔據100%，在完美主義的設計師眼裡，是無法接受的事情。而巧妙的占
比，可以讓元素在各個主流屏幕占據100%像素，完美展現設計意圖。
B.臨界點
臨界點（breakpoint）是指響應式網頁發生布局變化的關鍵點，如「當屏幕寬度小於480px時載入...樣式，當寬度在480px-
600px之間時載入…樣式」。響應式網頁理論上有無數種尺寸，我們不可能也沒有必要為每個尺寸都去做設計，需要做的是選定幾個臨界點做設計，在兩個臨界
點之間是延續上一個臨界點的布局。
臨界點確認總體目的就是為了保證頁面在手機（屏幕很小）、平板（屏幕中等）、PC（屏幕大）上載入相應的樣式，然而經驗較少的設計師往往會苦惱一個
問題，那就是高像素的手機屏幕和低像素的平板屏幕應如何處理。例如設計師會擔心1080p的手機載入大屏幕頁面，或者720p的平板載入小屏幕頁面。
但需要注意的是，響應式網頁不同於APP的屏幕適配。網頁是沉浸於瀏覽器的產品，瀏覽器所啟動的屏幕像素才可以被認為是臨界點的參考點，為此，筆者
做了一些測試，如下表，可以看出不少1080p手機在瀏覽器中僅啟動360px，而神奇的ipad無論是不是retina屏幕，無論是不是mini，均顯
示1024x768px 。
⑹ 如何使用Node.js構建微服務
其中一個選擇就是Node.js。它是輕量的、響應式的以及，它可以與常見的web數據類型良好的工作，包括JSON。其組合的特性使其成為微服務的理想主機，這樣用戶Node.js能夠快速構建服務，作為一項交換服務來處理API之間的 JSON。用戶很容易把Node.js作為一個軟體路由，來處理信息和響應。
⑺ 微服務架構下，進行前後端分離，前端怎麼寫
分離後的前端，不再是一個簡單的HTML文件，已經是一個獨立的應用系統。除了要考慮頁面的數據渲染展示，還要用工程化的思想來考慮前端的架構，前後端的交互和數據安全等事情。
RESTful介面交互
前後端分離之後，更多的是採用RESTful風格的介面與後端進行數據交互。
REST是「呈現狀態轉移（REpresentational State Transfer）」的縮寫，一種API的架構風格，在客戶端和服務端之間通過呈現狀態的轉移來驅動應用狀態的演進。
在 REST 樣式的 Web 服務中，每個資源都有一個地址。資源本身都是方法調用的目標，方法列表對所有資源都是一樣的。這些方法都是標准方法，包括 HTTP GET、POST、PUT、DELETE，還可能包括 HEADER 和 OPTIONS。
RESTful的API設計，使得後端通過介面向前端傳遞數據，數據的格式通常是JSON這種通用的格式。對前端來說，只要後端返回過來的是RESTful的數據就行，不管後端是用Java寫，還是用python或PHP，拜託對後端的依賴，做到前端系統的獨立。
工程化構建
Nodejs不止可以用來做前端伺服器，在開發階段，它也能發揮很大的作用。
前端生態的發展，是圍繞著Nodejs進行的。用npm來管理項目依賴，可以很好的維護和運行在Nodejs環境上。
打包工具grunt、gulp、webpack和rollup等，都是運行在nodejs上，再結合語法編譯、打包部署等插件，將應用輸入成一個完整的應用。
如果你使用了Angular、React或Vue框架，或者你使用瀏覽器暫時還不兼容的ES6語法，還需要在應用打包前用babel將語法編譯成瀏覽器可識別的ES5的語法。
SPA
SPA是單頁Web應用（single page web application，SPA）的簡寫，就是只有一張Web頁面的應用，是載入單個HTML 頁面並在用戶與應用程序交互時動態更新該頁面的Web應用程序。
像Angular、React或Vue就是為了SPA而設計的，結合前端路由庫（react-router、vue-router）和狀態熱存儲（rex、vuex）等，可以開發出一個媲美Native APP的Web APP，用戶體驗得到了很大的提升。
當然，SPA也不是完美的，也不是適合所有的web應用，需要結合項目和場景來選擇。
SPA有如下缺點：
初次載入耗時增加。可以通過代碼拆分、懶載入來提升性能，減少初次載入耗時。
SEO不友好，現在可以通過Prerender或Server render來解決一部分。
頁面的前進和後端需要開發者自己寫，不過現在一些路由庫已經幫助我們基本解決了。
對開發者要求高，由於做SPA需要了解一整套技術棧，所以，要考慮後期是否有合適的人選進行維護。
⑻ 微服務中 web層和service層要分開工程嗎
Spring IO platform:用於系統部署，是可集成的，構建現代化應用的版本平台，具體來說當你使用maven dependency引入spring jar包時它就在工作了。
Spring Boot:旨在簡化創建產品級的 Spring 應用和服務，簡化了配置文件，使用嵌入式web伺服器，含有諸多開箱即用微服務功能，可以和spring cloud聯合部署。
⑼ 如何在Kubernetes上進行微服務部署
使用Rancher來運行Kubernetes有很多優勢。大多數情況下能使用戶和IT團隊部署和管理工作更加方便。Rancher自動在Kubernetes後端實現etcd 的HA，並且將所需要的服務部署到此環境下的任何主機中。在設置訪問控制，可以輕易連接到現有的LDAP和AD基礎構架。Rancher還可以自動實現容器聯網以及為Kubernetes提供負載均衡服務。通過使用Rancher，你將會在幾分鍾內有擁有Kubernetes的HA實現。
命名空間
現在我們的集群已經運行了，讓我們進入並查看一些基本的Kubernetes資源吧。你可以訪問Kubernetes集群也可以直接通過kubectl CLI訪問，或者通過Rancher UI 訪問。Rancher的訪問管理圖層控制可以訪問集群，所以你需要在訪問CLI前從Rancher UI那裡生成API密匙。
我們來看下第一個Kubernetes資源命名空間，在給定的命名空間中，所有資源名稱必須有唯一性。此外,標簽是用來連接劃定到單個命名空間的資源。這就是為什麼同一個Kubernetes集群上可以用命名空間來隔離環境。例如，你想為應用程序創建Alpha, Beta和生產環境，以便可以測試最新的更改且不會影響到真正的用戶。最後創建命名空間，復制下面的文本到namespace.yaml文件，並且運行 kubectl -f namespace.yaml 命令，來創建一個beta命名空間。
kind: Namespace
apiVersion: v1
metadata:
name: beta
labels:
name: beta
當然你還可以使用頂部的命名空間菜單欄從Rancher UI上創建、查看和選擇命名空間。
你可以使用下面的命令，用kubectl來為CLI交互設置命名空間：
$ kubectl config set-context Kubernetes --namespace=beta.
為了驗證目前context是否已經被設置好，你可以使用config view命令，驗證一下輸出的命名空間是否滿足你的期望。
$ kubectl config view | grep namespace command namespace: beta
Pods
現在我們已經定義好了命名空間，接下來開始創建資源。首先我們要看的資源是Pod。一組一個或者多個容器的Kubernetes稱為pod，容器在pod 里按組來部署、啟動、停止、和復制。在給定的每個主機種類里，只能有一個Pod,所有pod里的容器只能在同一個主機上運行，pods可以共享網路命名空間,通過本地主機域來連接。Pods也是基本的擴展單元,不能跨越主機,因此理想狀況是使它們盡可能接近單個工作負載。這將消除pod在擴展或縮小時產生的副作用，以及確保我們創建pods不太耗資源而影響到主機。
我們來給名為mywebservice的pod定義，在規范命名web-1-10中它有一個容器並使用nginx容器鏡像，然後把埠為80下的文本添加至pod.yaml文檔中。
apiVersion: v1
kind: Pod
metadata:
name: mywebservice
spec:
containers:
- name: web-1-10
image: nginx:1.10
ports:
- containerPort: 80
使用kubetl create命令創建pod，如果您使用set-context command設置了您的命名空間，pods將會在指定命名空間中被創立。在通過運行pods命令去驗證pod狀態。完成以後，我們可以通過運行kubetl delete命令刪除pod。
$ kubectl create -f ./pod.yaml
pod "mywebservice" created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mywebservice 1/1 Running 0 37s
$ kubectl delete -f pod.yaml
pod "mywebservice" deleted
在Rancher UI 中查看pod，通過頂端的菜單欄選擇 Kubernetes > Pods 。