㈠ Spring Cloud微服務體系的組成
Netflix Eureka是Spring Cloud服務注冊發現的基礎組件
Eureka提供RESTful風格(HTTP協議)的服務注冊與發現
Eureka採用C/S架構,Spring Cloud內置客戶端
啟用應用,訪問 http://localhost:8761
Eureka客戶端開發要點
maven依賴spring-cloud-starter-netflix-eureka-client application.yml
配置eureka.client.service-url.defaultZone
入口類增加@EnableEurekaClient
先啟動注冊中心,在啟動客戶端,訪問 localhost:8761查看eureka注冊中心,看到客戶端注冊
Eureka名詞概念
Register - 服務注冊, 向Eureka進行注冊登記
Renew - 服務續約,30秒/次心跳包健康檢查.90秒未收到剔除服務
Fetch Registries - 獲取服務注冊列表,獲取其他微服務地址
Cancel - 服務下線, 某個微服務通知注冊中心暫停服務
Eviction - 服務剔除,90秒未續約,從服務注冊表進行剔除
Eureka自我保護機制
Eureka在運行期去統計心跳失敗率在15分鍾之內是否低於 85%
如果低於 85%，會將這些實例保護起來，讓這些實例不會被剔除
關閉自我保護:eureka.服務實例.
enable-self-preservation: false
PS: 如非網路特別不穩定,建議關閉
Eureka高可用配置步驟
服務提供者defaultZone指向其他的Eureka
客戶端添加所有Eureka 服務實例 URL
Actuator自動為微服務創建一系列的用於監控的端點
Actuator在SpringBoot自帶，SpringCloud進行擴展
pom.xml依賴spring-boot-starter-actuator
RestTemplate + @LoadBalanced 顯式調用
OpenFeign 隱藏微服務間通信細節
Ribbon是RestTemplate與OpenFeign的通信基礎
Feign是一個開源聲明式WebService客戶端，用於簡化服務通信
Feign採用「介面+註解」方式開發，屏蔽了網路通信的細節
OpenFeign是SpringCloud對Feign的增強，支持Spring MVC註解
1.新建Spring boot Web項目，application name 為 proct-service
在pom.xml中引入依賴
spring-cloud-starter-alibaba-nacos-discovery作用為向Nacos server注冊服務。
spring-cloud-starter-openfeign作用為實現服務調用。
2.修改application.yml配置文件
3.在啟動類上添加@EnableDiscoveryClient、@EnableFeignClients註解
4.編寫OrderClient Interface
註：/api/v1/order/test 會在下面order-service聲明。
OrderClient.java
5.編寫Controller和service
ProctController.java
ProctService.java
1.OpenFeign開啟通信日誌
基於SpringBoot的logback輸出,默認debug級別
設置項：feign.client.config.微服務id.loggerLevel
微服務id：default代表全局默認配置
2.通信日誌輸出格式
NONE: 不輸出任何通信日誌
BASIC: 只包含URL、請求方法、狀態碼、執行時間
HEADERS：在BASIC基礎上，額外包含請求與響應頭
FULL：包含請求與響應內容最完整的信息
3.OpenFeign日誌配置項
LoggerLevel開啟通信日誌
ConnectionTimeout與ReadTimeout
利用httpclient或okhttp發送請求
1.OpenFeign通信組件
OpenFeign基於JDK原生URLConnection提供Http通信
OpenFeign支持Apache HttpClient與Square OkHttp
SpringCloud按條件自動載入應用通信組件
2.應用條件
Maven引入feign-okhttp或者feign-httpclient依賴
設置feign.[httpclient|okhttp].enabled=true
POST方式傳遞對象使用@RequestBody註解描述參數
GET方式將對象轉換為Map後利用@RequestParam註解描述
雪崩效應:服務雪崩效應產生與服務堆積在同一個線程池中，因為所有的請求都是同一個線程池進行處理，這時候如果在高並發情況下，所有的請求全部訪問同一個介面,這時候可能會導致其他服務沒有線程進行接受請求，這就是服務雪崩效應效應。
服務熔斷:熔斷機制目的為了保護服務，在高並發的情況下，如果請求達到一定極限(可以自己設置闊值)如果流量超出了設置閾值，讓後直接拒絕訪問，保護當前服務。使用服務降級方式返回一個友好提示，服務熔斷和服務降級一起使用。
1.Hystrix熔斷器
Hystrix（豪豬）是Netflix開源的熔斷器組件，用於為微服務提供熔斷機制預防雪崩，保護整體微服務架構的健康
2.Hystrix功能
預防微服務由於故障，請求長時間等待導致Web容器線程崩潰
提供故障備選方案，通過回退（fallback)機制提供」服務降級」
提供監控儀表盤,實時監控運行狀態
3.Hystrix 熔斷器工作原理
服務的健康狀況 = 請求失敗數 / 請求總數.
熔斷器開關由關閉到打開的狀態轉換是通過當前服務健康狀況和設定閾值比較決定的.
當熔斷器開關關閉時, 請求被允許通過熔斷器. 如果當前健康狀況高於設定閾值, 開關繼續保持關閉. 如果當前健康狀況低於
設定閾值, 開關則切換為打開狀態.
當熔斷器開關打開時, 請求被禁止通過.
當熔斷器開關處於打開狀態, 經過一段時間後, 熔斷器會自動進入半開狀態, 這時熔斷器只允許一個請求通過. 當該請求調用
成功時, 熔斷器恢復到關閉狀態. 若該請求失敗, 熔斷器繼續保持打開狀態, 接下來的請求被禁止通過.
熔斷器的開關能保證服務調用者在調用異常服務時, 快速返回結果, 避免大量的同步等待. 並且熔斷器能在一段時間後繼續偵測請求執行結果, 提供恢復服務調用的可能.
4.什麼情況下會觸發服務降級
FAILURE: 執行失敗，拋出異常
TIMEOUT:執行超時（默認1秒）
SHORT_CIRCUITED:熔斷器狀態為Open
THREAD_POOL_REJECTED:線程池拒絕
SEMAPHORE_REJECTED:信號量拒絕
5.使用Hystrix步驟
1.引入pom文件依賴
6.OpenFeign與Hystrix整合
OpenFeign中使用Hystrix
OpenFeign內置Hystrix，feign.hystrix.enable開啟即可
feign: hystrix: enabled: true
在@FeignClient增加fallback屬性說明Fallback類
@FeignClient(name="message-service",fallback = MessageServiceFallback.class) public interface MessageService { @GetMapping("/sendsms") public CallbackResult sendSMS(@RequestParam("mobile") String mobile , @RequestParam("message") String message); }
Fallback類要實現相同介面，重寫服務降級業務邏輯
@Component public class MessageServiceFallback implements MessageService { @Override public CallbackResult sendSMS(String mobile, String message) { return new CallbackResult("INVALID_SERVICE","消息服務暫時無法使用，簡訊發送失敗"); } }
7.Hystrix超時設置
8.部署Hystrix Dashboard監控
Hystrix Client依賴hystrix-metrics-event-stream
Hystrix Client注冊HystrixMetricsStreamServlet
監控微服務依賴spring-cloud-starter-netflix-hystrix-dashboard
監控微服務利用@EnableHystrixDashboard開啟儀表盤
9.Hystrix熔斷設置
產生熔斷的條件:
當一個Rolling Window(滑動窗口）的時間內（默認：10秒），最近20次調用請求，請求錯誤率超過50%，則觸發熔斷5秒，期間快速失敗。
TIPS: 如10秒內未累計到20次，則不會觸發熔斷
Hystrix熔斷設置項:
統一訪問出入口,微服務對前台透明
安全、過濾、流控等API管理功能
易於監控、方便管理
Netflix Zuul
Spring Cloud Gateway
Zuul 是Netflix開源的一個API網關, 核心實現是Servlet
Spring Cloud內置Zuul 1.x
Zuul 1.x 核心實現是Servlet，採用同步方式通信
Zuul 2.x 基於Netty Server，提供非同步通信
認證和安全
性能監測
動態路由
負載卸載
靜態資源處理
壓力測試
Spring Cloud Gateway，是Spring「親兒子」
Spring Cloud Gateway旨在為微服務架構提供一種簡單而有效的統一的API路由管理方式
Gateway基於Spring 5.0與Spring WebFlux開發，採用Reactor響應式設計
1.使用三部曲
依賴spring-cloud-starter-netflix-zuul
入口增加 @EnableZuulProxy
application.yml 增加微服務映射
2.微服務映射
Spring Cloud Zuul內置Hystrix
服務降級實現介面：FallbackProvider
1.微服務網關流量控制
微服務網關是應用入口，必須對入口流量進行控制
RateLimit是Spring Cloud Zuul的限流組件
https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit
RateLimit採用「令牌桶」演算法實現限流
2.什麼是令牌桶
1.Zuul的執行過程
2.Http請求生命周期
1.需要實現ZuulFilter介面
shouldFilter() - 是否啟用該過濾器
filterOrder() - 設置過濾器執行次序
filterType() - 過濾器類型:pre|routing|post
run() - 過濾邏輯
2.Zuul內置過濾器
3.Zuul+JWT跨域身份驗證
1.Spring Cloud Config
2.攜程 Apollo
3.阿里巴巴Nacos
1.依賴"spring-cloud-starter-config"
2.刪除application.yml,新建bootstrap.yml
3.配置"配置中心"服務地址與環境信息
1、微服務依賴"spring-boot-starter-actuator";
2、動態刷新類上增加@RefreshScope註解
3、通過/actuator/refresh刷新配置
1、通過加入重試機制、提高應用啟動的可靠性;
2、重試觸發條件1:配置中心無法與倉庫正常通信
3、重試觸發條件2:微服務無法配置中心正常通信
㈡ 反應式微服務框架Flower
Flower是一個構建在Akka上的反應式微服務框架，開發者只需要針對每一個細粒度的業務功能開發一個Service服務，並將這些Service按照業務流程進行可視化編排，即可得到一個反應式系統。
Flower既是一個反應式編程框架，又是一個分布式微服務框架。
Flower框架使得開發者無需關注反應式編程細節，即可得到一個反應式系統。
快速上手
Flower框架的主要元素包括：Flower Service（服務）、Flower 流程和Flow容器。Service實現一個細粒度的服務功能，Service之間通過Message關聯，前一個Service的返回值（Message），必須是後一個Service的輸入參數（Message），Service按照業務邏輯編輯成一個Flow（流程），Flower容器負責將前一個Service的返回消息，傳遞給後一個Service。
安裝
Maven
Gradle
SBT
Ivy
Flower初始化
Flower使用前需要進行初始化，這里演示最簡單的方式。
Flower初始化
定義Flower服務
開發Service類必須實現Flower框架的Service介面或者繼承AbstractService基類，在process方法內完成服務業務邏輯處理。
UserServiceA
UserServiceB
UserServiceC1
服務注冊
Flower提供兩種服務注冊方式：配置文件方式和編程方式。
服務流程編排
Flower框架提供兩種服務流程編排方式：配置文件方式和編程方式。
兩種編排方式的結果是一樣：
調用Flower流程
前面定義了3個Flower服務，並編排了名稱為flower_test的服務流程。那麼怎麼使用它呢？
完整示例
在Flower裡面消息是一等公民，基於Flower開發的應用系統是面向消息的應用系統。 消息由Service產生，是Service的返回值；同時消息也是Service的輸入。前一個Service的返回消息是下一個Service的輸入消息，沒有耦合的Service正是通過消息關聯起來，組成一個Service流程，並最終構建出一個擁有完整處理能力的應用系統。流程舉例：
術語
Flower消息處理模式
消息除了將服務串聯起來，構成一個簡單的串列流程，還可以組合應用，產生更強大的功能。
消息分叉
消息分叉是指，一個服務輸出的消息，可能產生分叉，分發給1個或者多個其他服務。消息分叉後有兩種處理方式，全部分發和條件分發。
全部分發
將輸出消息分發給全部流程後續服務。後續多個服務接受到消息後，並行執行。這種模式多用於可並行執行的多個子任務，比如用戶注冊成功後，需要1、將用戶數據寫入資料庫，2、給用戶發送激活郵件，3、給用戶發送通知簡訊，4、將新用戶注冊信息發送給關聯產品，實現賬戶打通。上述4個服務就可以採用消息全部分發模式，接受用戶注冊消息，並發完成上述4個任務。
要實現消息全部分發，需要在流程中進行配置，所有需要接受前序服務的輸出消息的服務都要配置在流程中，如
service1是前序服務，service2和service3是後繼服務。 如果service2和service3的class定義中，實現Service介面的聲明中指定了泛型，則泛型類型必須是service1的輸出類型或者其父類。
Service1
Service2
Service3
條件分發
有時候，前一個服務產生的消息，根據消息內容和業務邏輯可能會交給後續的某一個服務處理，而不是全部服務處理。比如用戶貸款申請，當前服務計算出用戶信用等級後，需要根據信用等級判斷採用何種貸款方式，或者是拒絕貸款，不同貸款方式和拒絕貸款是不同的服務，這些服務在流程配置的時候，都需要配置為前序服務的後繼服務，但是在運行期根據條件決定將消息分發給具體哪個後繼服務。
實現條件分發在流程配置上和全部分發一樣，所有可能的後繼服務都要配置在流程中。具體實現條件分發有如下三種方式。
根據泛型進行分發
後續服務實現介面的時候聲明不同的泛型類型，前序服務根據業務邏輯構建不同的消息類型，Flower會根據消息類型匹配對應的服務，只有成功匹配，消息才發送給過去。比如：
構建流程
聲明ServiceB接受的消息類型為MessageB
ServiceA
ServiceB是ServiceA的後續服務，ServiceA收到的消息如果是字元串「b」，就會返回消息類型B，這時候框架就會將消息發送給ServiceB，而不會發送給ServiceC。
在消息中指定後繼服務的id進行分發
前序消息實現Condition介面，並指定後繼服務的id，如：
一般說來，服務是可復用的，可復用於不同的流程中，但是在不同的流程中後繼服務可能是不同的，後繼服務的id也是不同的，在服務中寫死後續服務id，顯然不利於服務的復用。解決方案有兩種，一種是在不同的流程中，寫一個專門用於分發的服務，也就是處理業務邏輯的服務並不關心消息的分發，只管返回消息內容，但是其後繼服務是一個專門用來做消息分發的服務，這個服務沒有業務邏輯，僅僅實現Condition介面根據消息內容指定後繼服務。
另一種是使用框架內置服務ConditionService進行消息分發
使用框架內置服務ConditionService進行消息分發
ConditionService是一個通用的消息分發服務，
服務serviceE要將消息根據條件分發給serviceF或者serviceG，流程配置如上，中間加入serviceCondition進行適配。 serviceCondition的服務注冊方法為
com.ly.train.flower.common.service.ConditionService為框架內置服務
這種方式中，依然需要在serviceCondition的前驅服務serviceE中設置返回消息的condition，但是不必設置後續服務的id，只需要設置後續服務的順序號即可。
幾種條件分發的代碼示例參考/flower.sample/src/main/java/com/ly/train/flower/common/sample/condition/Sample.java
消息聚合
對於全部分發的消息分叉而言，通常目的在於使多個服務能夠並行執行，加快處理速度。通常還需要得到這些並行處理的服務的全部結果，進行後續處理。 在Flower中，得到多個並行處理服務的結果消息，稱為消息聚合。實現方式為，在流程中，配置需要聚合的多個消息的後續服務為com.ly.train.flower.common.service.AggregateService，這是一個框架內置服務，負責聚合多個並行服務產生的消息，將其封裝到一個Set對象中返回。 如流程
這里的service5就是一個消息聚合服務，負責聚合並行的service2和service3產生的消息，並把聚合後的Set消息發送給service4. 服務配置如下，service5配置為框架內置服務AggregateService。
service4負責接收處理聚合後的消息，從Set中取出各個消息，分別處理。
消息回復
Flower中的消息全部都是非同步處理，也就是服務之間不會互相阻塞等待，以實現低耦合、無阻塞、高並發的響應式系統。Flower流程調用者發送出請求消息以後，消息在流程中處理，調用者無需阻塞等待處理結果，可以繼續去執行其他的計算任務。
和傳統的命令式編程不同，通常流程的發起調用者並不是流程處理結果的最終接受者，比如對於web開發，流程的發起者通常是一個servlet，但是真正接受處理結果的是用戶端瀏覽器或者App，流程中的服務可以直接發送處理結果給用戶端，而不必通過servlet。也就是調用發起者servlet無需等待流程服務的最終處理結果，將用戶請求發送到流程中後，不必阻塞等待處理，可以立即獲取另一個用戶的請求繼續進行處理。
但是Flower也支持調用者阻塞等待消息處理結果，消息回復模式可以使流程調用者得到流程處理的最終結果消息。可參考代碼示例 /flower.sample/src/main/java/com/ly/train/flower/common/sample/textflow/Sample.java
Flower web開發模式
Flower集成Servlet3的web開發模式
Flower支持Servlet3的非同步模式，請求處理線程在調用Flower流程，並傳入AsyncContext對象後立即釋放。 代碼示例參考/flower.sample/src/main/java/com/ly/train/flower/common/sample/web/async/AsyncServlet.java
開發支持Servlet3的Flower服務，需要實現框架的Service介面，在方法 Object process(T message, ServiceContext context) throws Exception;中，Flower框架會傳入一個Web對象，通過context.getWeb()得到Web對象，用以獲得請求參數和輸出處理響應結果。
Flower集成Spring boot的web開發模式
Flower支持Spring boot開發，在項目中依賴flower.web，實現框架中的Service介面和InitController介面。 初始化@BindController註解需要的參數，在編譯過程中自動由flower.web枚舉@BindController註解, 生成Spring boot需要的Controller。
注意： flower.web利用annotation為Service生成spring boot所需的Controller類。這個生成過程在程序編譯的時候完成，如果IDE環境不支持熱編譯，需要在命令行執行mvn install生成代碼。
代碼示例參考/flower.sample/src/main/java/com/ly/train/flower/common/sample/springboot
使用Flower框架的開發建議
Flower分布式部署架構
開發流程
一. 啟動Flower.center注冊中心
二. 開發Flower Service，啟動業務服務Flower容器，自動向注冊中心注冊服務
三. 開發Flower web網關，啟動Flower網關服務，編排流程
一. 注冊中心
Flower.center基於spring-boot開發，通過打包成fat-jar後通過命令行啟動即可。
Flower注冊中心啟動入口/flower.center/src/main/java/com/ly/train/flower/center/CenterApplication.java Flower注冊中心啟動命令java -jar flower.center-0.1.2.jar
二. 啟動業務Flower容器
Flower部署支持Flower容器和Spring容器，下面的例子基於spring-boot演示
2.1 創建配置文件flower.yml
2.2 配置FlowerFactory
2.3 開發flower服務
2.4 創建啟動類
三. 啟動網關伺服器，編排流程
3.1 創建flower.yml
3.2 配置FlowerFactory
3.3 開發Flower服務
3.4 開發網關Controller
3.5 啟動類
實例項目細節
flower分布式實例 https://github.com/leeyazhou/flower.showcase.git
核心概念
FlowerFactory
使用默認的FlowerFactory
按需創建自己的FlowerFactory，配置文件路徑默認讀取classpath:flower.yml,配置文件內容格式為yaml風格，詳情查看配置信息。
獲取FlowerFactory之後，就可以使用它提供的介面：
FlowRouter流程路由器，創建流程之後，通過FlowerFactory可以創建出對應的路由器，之後便可以進行服務的調用了。
分布式
Flower.yml配置信息
了解關於Flower的內部設計，有助於你更好地利用Flower開發一個反應式系統。
Flower core模塊（進程內流式微服務框架）設計
Flower基於Akka的Actor進行開發，將Service封裝到Actor裡面，Actor收到的消息作為參數傳入Service進行調用，Service的輸出發送給後續Actor作為Service的輸入。
Flower核心類
Flower初始化及調用時序
服務流程初始化
消息流處理
Flower的核心設計不過如此。但是由此延伸出來的應用方法和設計模式卻和Akka有了極大的不同。
分布式流式微服務框架設計
傳統的分布式微服務框架通過遠程調用的方式實現服務的解耦與分布式部署，使得系統開發、維護、服務復用、集群部署更加方便靈活，但是這種微服務依然許多不足之處
流式微服務框架Flower致力於構建一種新的微服務架構體系，使用流式計算的架構思想，以一種更加輕量、更易於設計開發、消息驅動、弱依賴，非同步並發的技術特點開發實現微服務系統
架構
部署模型
Flower將整個應用系統集群統一管理控制，控制中心控制管理集群的所有資源
Agent部署在集群每一台伺服器上，負責載入服務實例，並向控制中心匯報狀態
代碼倉庫負責管理服務的java程序包，程序包用assembly打包
控制中心和Agent基於Akka開發，每個服務包裝一個actor裡面，actor之間負責消息的通信
集群啟動與服務部署時序模型
注冊服務數據結構
服務之間的依賴關系在控制中心編排
㈢ microk8s處理微服務之間的調用
通過在 microk8s上部署授權服務 ，我們基本上走通了微服務通過配置中心服務（config-central）載入配置並啟自己的流程。
在microk8s上部署微服務，現在僅剩下一個需要處理的問題，微服務之間通的互相調用。這里我們用我們微服務集群里的base-service 和 diagnose-service來嘗試整個流程。
base服務主要提供平台的基礎數據，像配置授權服務一樣，我們需要寫configmap、deployment、service三個yaml配置文件。
整體上與授權服務沒多大區別，但又兩個地方這次需要特別注意：
1. 標黃的context-path的配置， springboot2.0 需要使用：
server.servlet.context-path= xxxx
如果仍沿用1.0的配置， 啟動時contexnt將為『』。
2. 必須正確配置virtualHostName, 這個參數配置，會導致ribbion找不到base服務， 我就因為填寫錯誤，被整了一兩天，後來在介紹Ribbon原理的一篇文章里，發現：
從eureka服務獲取服務列表，服務集群必須由VipAddress標識
Base服務的Deployment文件，沒有什麼特別的，和Authorize基本一樣：
Service文件，我們仍舊定義為Nodeport方便測試：
部署完成後，我們使用port-forward 命令做個埠映射。
microk8s kubectl port-forward pod/baseservice-79946b574d-kqf8x 8000:9043
通過瀏覽器訪問localhost:8000埠，就可以訪問服務了。
部署完base服務，我們來看看怎麼讓diagnose服務調用base服務。
1. 需要在diagnose服務的入口，聲明@enableEurekaClient 和 @enableFeignClients
2. 建立feign的介面文件
Name 是我們需要需要調用的微服務名，這個名字一定要注意：
1. 都使用小寫， 因為k8s對服務名有要求。
2. 這個一定對應的是相應服務的virtualHostName, 否者找不著。
當然需要載入相應的cloud包，最好通過springboot提供的工具生成。
現在需要來寫配置文件configmap,這個配置文件與base服務差不多，唯一區別就是標黃的
部分， 確保自動獲取打開，另外使用主動加在服務。
通過上面的配置，我們在啟動服務就可以看到，baseservice將被從注冊中心獲取並房子啊serverlist里。
Deployment和service的書寫與base服務沒有任何區別，這里就省略了。完成部署後，我們通過postman做測試，可以正確返回結果。
Notes： diagnose服務的conext因為沒有正確配置，所以IP和埠後直接接了restful請求路徑了，這個需要注意。
檢查base服務，可以看到，確實調用了介面。
至此，服務間的調用初步走通了，現在我們還需要做一件事，就是將base服務在注冊中心注冊的IP改為k8s中的服務名稱，只需要在configmap中增加如下屬性:eureka.instance.ip-address= baseservice
然後，更新配置文件和deployment文件，重啟服務。查看base服務注冊中的記錄，可以看到hostname和ipaddr已經正確顯示服務名稱。
重新通過postman調用diagnose服務發現，報錯，調用base服務沒響應。只好重啟diagonose服務，查看日誌：
啟動後，服務列表已經正確填充了base服務：baseservice:9043
現在重新測試介面，正常返回結果。看來需要正確的設置，feign得自動刷新參數，否則發生服務名變化後，本地緩存不能及時清理，會導致無法正常工作。
走到這里，基本上在microk8s上部署服務，並實現服務間的調用就完成了。在整個驗證過程中，深深地體會了，spring cloud的不好用：雖然看起來簡單，但 一不小心就可能配置錯誤， 而且很多功能其實k8s已經提供，完全可以掠過。 k8s中的服務，已經提供了loadbalance的作用, feign的使用其實已經沒有意義。
所以，雖然將舊的虛擬機環境的微服務遷移到k8s上，基本是走通了。但是我們還需要做的更進一步，剔除springcloud的功能。
這樣，讓開發工程師，從繁雜的配置中解脫出來，完全可以增減團隊效率。
㈣ nginx 的配置文件用什麼腳本
本文詳細介紹了Nginx配置的一些參數說明，為以後的配置提供一定的幫助。有兩種方式來通過這些信號去控制
Nginx，第一是通過 logs 目錄下的 nginx.pid 查看當前運行的 Nginx 的進程 ID，通過 kill – XXX 來控制
Nginx。
AD：WOT2014課程推薦：實戰MSA：用開源軟體搭建微服務系統
檢測nginx配置文件是否正確
/usr/local/nginx/sbin/nginx -t -c nginx.conf
-c 配置文件路徑
-g Set global directives. (version >=0.7.4)
-t 檢測文件是否正確不執行
-v Print version.
-V Print nginx version, compiler version and configure parameters.
編譯時如果使用了–with-debug編譯,還可以使用error_log file [ debug_core| debug_http | debug_event …] 來獲得debug信息
通過信號對Nginx進行控制
Nginx支持下表中的信號：
信號名 作用描述
TERM, INT 快速關閉程序，中止當前正在處理的請求
QUIT 處理完當前請求後，關閉程序
HUP 重新載入配置，並開啟新的工作進程，關閉就的進程，此操作不會中斷請求
USR1 重新打開日誌文件，用於切換日誌，例如每天生成一個新的日誌文件
USR2 平滑升級可執行程序
WINCH 從容關閉工作進程
有兩種方式來通過這些信號去控制 Nginx，第一是通過 logs 目錄下的 nginx.pid 查看當前運行的 Nginx 的進程
ID，通過 kill – XXX <pid> 來控制 Nginx，其中 XXX 就是上表中列出的信號名。如果您的系統中只有一個
Nginx 進程，那您也可以通過 killall 命令來完成，例如運行 killall – s HUP nginx 來讓 Nginx
重新載入配置。
配置:
use [ kqueue | rtsig | epoll | /dev/poll | select | poll ];
FreeBSD使用kqueue，Linux選epoll.
worker_connections number 每個worker的最大連接數
Maxclient = work_processes *worker_connections
nginx的upstream目前支持4種方式的分配
1、輪詢（默認）
每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。
2、weight
指定輪詢幾率，weight和訪問比率成正比，用於後端伺服器性能不均的情況。
2、ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的問題。
3、fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
4、url_hash（第三方）
按訪問url的hash結果來分配請求，使每個url定向到同一個後端伺服器，後端伺服器為緩存時比較有效。
代理
只需要在nginx的配置文件中增加虛擬主機,然後加入
\proxy_pass http://localhost:8000;
負載均衡:
只需要在http中增加
upstream tgcluster {#定義負載均衡設備的Ip及設備狀態
ip_hash;
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
在需要使用負載均衡的server中增加
proxy_pass http://tgcluster/;
每個設備的狀態設置為:
1.down 表示單前的server暫時不參與負載
2.weight 默認為1.weight越大，負載的權重就越大。
3.max_fails ：允許請求失敗的次數默認為1.當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤
4.fail_timeout:max_fails次失敗後，暫停的時間。
5.backup： 其它所有的非backup機器down或者忙的時候，請求backup機器。所以這台機器壓力會最輕。
nginx支持同時設置多組的負載均衡，用來給不用的server來使用。
client_body_in_file_only 設置為On 可以講client post過來的數據記錄到文件中用來做debug
client_body_temp_path 設置記錄文件的目錄 可以設置最多3層目錄
location 對URL進行匹配.可以進行重定向或者進行新的代理 負載均衡
FASTCGI配置:
請將以下內容保存為fastcgi_params文件，保存於/usr/local/nginx/conf下（Ubuntu可保存於/etc/nginx下），他為我們的FastCGI模塊設置了基本的環境變數：
#fastcgi_params
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
# PHP only, required if PHP was built with –enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;
請特別注意加粗的一行，PHP-CGI特別需要此行信息來確定PHP文件的位置。
另外需要在PHP-CGI的配置文件（Ubuntu 上此配置文件位於/etc/php5/cgi/php.ini）中，打開cgi.fix_pathinfo選項：
cgi.fix_pathinfo=1;
這樣php-cgi方能正常使用SCRIPT_FILENAME這個變數。
接下來在nginx的配置中針對php文件配置其利用FastCGI進程來執行：
server {
index index.php;
root /usr/local/nginx/html;
location ~ .*.php$ {
include /usr/local/nginx/conf/fastcgi_params; #請根據自己保存的路徑進行設置
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000; #請根據自己的FastCGI綁定的地址和埠進行配置
}
}
通知Nginx重新載入配置:
kill -HUP `cat /usr/local/nginx/logs/nginx.pid`
Ubuntu用戶可以使用init腳本：sudo /etc/init.d/nginx reload
然後啟動php-cgi -b 127.0.0.1:9000
如果出現No input file specified表示SCRIPT_FILENAME設置的有問題。
使用lighttpd的 spawn-fcgi
get http://www.lighttpd.net/download/lighttpd-1.4.18.tar.bz2 #獲取Lighttpd的源碼包
tar -xvjf lighttpd-1.4.18.tar.bz2
cd lighttpd-1.4.18
./configure #編譯
make
cp src/spawn-fcgi /usr/local/bin/spawn-fcgi #取出spawn-fcgi的程序
下面我們就可以使用 spawn-fcgi 來控制php-cgi的FastCGI進程了
/usr/local/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -C 5 -u www-data -g www-data -f /usr/bin/php-cgi
參數含義如下
-f <fcgiapp> 指定調用FastCGI的進程的執行程序位置，根據系統上所裝的PHP的情況具體設置
-a <addr> 綁定到地址addr
-p <port> 綁定到埠port
-s <path> 綁定到unix socket的路徑path
-C <childs> 指定產生的FastCGI的進程數，默認為5（僅用於PHP）
-P <path> 指定產生的進程的PID文件路徑
-u和-g FastCGI使用什麼身份（-u 用戶 -g 用戶組）運行，Ubuntu下可以使用www-data，其他的根據情況配置，如nobody、apache等
㈤ Spring Cloud
本文中我們主要介紹微服務開發框架——Spring Cloud。盡管Spring Cloud帶有"Cloud"的字樣，但它並不是雲計算解決方案，而是Spring Boot的基礎上構建的，用於快速構建分布式系統的通用模式的工具集。
Spring Cloud有以下特點:
由上圖可知，Spring Cloud是以 英文單詞+SR+數字 的形式命名版本號的。那麼英文單詞和SR分別表示什麼呢？
因為Spring Cloud是一個綜合項目，它包含很多子項目。由於子項目也維護著自己的版本號，Spring Cloud採用了這種命名方式，從而避免與子項目的版本混淆。其中英文單詞如Edware是倫敦某地鐵站名，它們按照字母順序發行，可以將其理解為主版本的演進。SR表示"Service Release"，一般表示Bug修復。
版本兼容性如下
版本內容
可參考官方文檔： https://spring.io/projects/spring-cloud#overview
我的上一篇博客(微服務理論篇)中談到，對單體應用進行服務拆分得到各個微服務，而這些服務又是相互獨立的，那麼我們如何知道各個微服務的健康狀態、如何知道某個微服務的存在呢？由此、一個擁有服務發現的框架顯得尤為重要。這也就是Eureka誕生的原因。
綜上，Eureka通過心跳檢查、客戶端緩存等機制，確保了系統的高可用性、靈活性和可伸縮性。
通過使用Eureka已經實現了微服務的注冊與發現。啟動各個微服務時，Eureka Client會把自己的網路信息注冊到Eureka Server上。似乎一切更美好了一些。然而，這樣的架構依然有一些問題，如負載均衡。一般來說，各個微服務都會部署多個實例。那麼服務消費者要如何將請求分攤到多個服務提供實例上呢？
如果服務提供者相應非常慢，那麼消費者對提供者的請求就會被強制等待，知道提供者響應或超時。在高負載場景下，如果不作任何處理，此類問題可能會導致服務消費者的資源耗竭甚至整個系統崩潰。
微服務架構的應用系統通常包含多個服務層。微服務之間通過網路進行通信，從而支撐起整個應用系統，因此，微服務之間難免存在依賴關系。而這種由於"基礎服務故障"導致"級聯故障"的現象稱為雪崩效應。
如圖所示，A最為服務提供者（基礎服務），B為A的服務消費者，C和D是B的服務消費者。當A不可用引起了B的不可用，並將不可用像滾雪球一樣放大到C和D時，雪崩效應就形成了。
那麼Hystrix是如何容錯的呢？
以下對該圖做個簡單講解：
Zuul作為微服務架構中的微服務網關。微服務架構經過前幾個組件的組合，已經有了基本的雛形了，那麼我們為什麼還要使用微服務網關呢？我們可以想像，一般情況下我們一個業務並不是只調用一個介面就可以完成一個業務需求。
如果讓客戶端直接與各個微服務通信，會有以下問題：
如圖，微服務網關封裝了應用程序的內部結構，客戶端只須跟網關交互，而無須直接調用特定微服務介面。同時，還有以下優點：
為什麼要同一管理微服務配置？
對於傳統的單體應用，常常使用配置文件管理所有配置。例如一個Spring Boot 項目開發的單體應用，可以將配置內容放到application.yml文件中。如果需要切換環境，可以設置多個Profile,並在啟用應用時指定spring.profile.active={profile}。
而在微服務架構中，微服務的配置管理一般有以下需求：
㈥ 微服務中如何獲取配置文件以及多環境切換配置
同關閉系統還原沒有關系！同AVAST有關系！ windows xp 速度提升和優化指南 Win XP以其華麗的操作畫面和穩定的性能成為不少電腦玩家的首選操作系統，但在使用Windows XP的過程中你會發現，隨著時間的推移操作系統在速度上是越來越慢了。
㈦ 微服務啟用自帶tomcat如何配置
自帶的程序設置的時候，只需要我們打開服務信息，然後完成服務信息，後台數據載入載入完成，再設置高等參數，處理信息即可。
㈧ 基於docker部署的微服務架構（二）： 服務提供者和調用者
前一篇 基於docker部署的微服務架構（一）：服務注冊中心 已經成功創建了一個服務注冊中心，現在我們創建一個簡單的微服務，讓這個服務在服務注冊中心注冊。然後再創建一個調用者，調用此前創建的微服務。
新建一個maven工程，修改pom.xml引入 spring cloud 依賴:
在 resources 目錄中創建 application.yml 配置文件，在配置文件內容:
這里eureka的注冊地址為上一篇中設置的defaultZone。
在 java 目錄中創建一個包 demo ，在包中創建啟動入口 AddServiceApplication.java
在demo包下新建一個子包controller，在controller子包下創建一個controller對外提供介面。
在服務注冊中心已經運行的情況下，運行 AddServiceApplication.java 中的 main 方法，啟動微服務。
訪問服務注冊中心頁面 http://localhost:8000 ， 可以看到已經成功注冊了 ADD-SERVICE-DEMO 服務。
啟動第二個實例，修改埠為 8101 ，修改 AddController.java 中的輸出信息為
再次運行 AddServiceApplication.java 中的 main 方法。
訪問服務注冊中心頁面 http://localhost:8000 ， 可以看到已經成功注冊了兩個 ADD-SERVICE-DEMO 服務，埠分別為 8100 和 8101 。
新建一個maven工程，修改pom.xml引入 spring cloud 依賴:
在 resources 目錄中創建 application.yml 配置文件，在配置文件內容:
在 java 目錄中創建一個包 demo ，在包中創建啟動入口 RibbonClientApplication.java
這里配置了一個可以從服務注冊中心讀取服務列表，並且實現了負載均衡的 restTemplate 。
在demo包下新建一個子包controller，在controller子包下創建一個controller對外提供介面。
可以看到這里的請求url用了服務注冊中心對應的 Application 。
運行 RibbonClientApplication.java 中的 main 方法，啟動項目。
在瀏覽器中訪問 http://localhost:8200/add?a=1&b=2 ，得到返回結果：
多次訪問，查看 AddServiceApplication 的控制台，可以看到兩個 ADD-SERVICE-DEMO 被負載均衡的調用。
demo源碼 spring-cloud-1.0/ribbon-client-demo
新建一個maven工程，修改pom.xml引入 spring cloud 依賴:
在 resources 目錄中創建 application.yml 配置文件，在配置文件內容:
在 java 目錄中創建一個包 demo ，在包中創建啟動入口 FeignClientApplication.java
在demo包下新建一個子包service，在service子包下創建一個介面 AddService.java 調用之前創建的微服務 ADD-SERVICE-DEMO 。
這里 @FeignClient 註解中的參數為服務注冊中心對應的 Application 。
在demo包下再新建一個子包controller，在controller子包下創建一個 FeignController.java 對外提供介面。
FeignController 里注入了剛才創建的 AddService 介面。
運行 FeignClientApplication.java 中的 main 方法，啟動項目。
在瀏覽器中訪問 http://localhost:8300/add?a=1&b=2 ，得到返回結果：
多次訪問，查看 AddServiceApplication 的控制台，可以看到兩個 ADD-SERVICE-DEMO 被負載均衡的調用。
demo源碼 spring-cloud-1.0/feign-client-demo
以 add-service-demo 為例，
復制 application.yml ，重命名為 application-docker.yml ，修改 defaultZone 為：
這里修改了 defaultZone 的訪問url，如何修改取決於部署docker容器時的 --link 參數， --link 可以讓兩個容器之間互相通信。
修改 application.yml 中的 spring 節點為：
這里增加了 profiles 的配置，在maven打包時選擇不同的profile，載入不同的配置文件。
在pom.xml文件中增加：
選擇 docker profile，運行 mvn install -P docker ，打包項目並生成docker鏡像， 注意docker-maven-plugin中的 <entryPoint> 標簽里的內容不能換行，否則在生成docker鏡像的時候會報錯 。
運行成功後，登錄docker節點，運行 docker images 應該可以看到剛才打包生成的鏡像了。
在前一篇中，已經創建了一個 service-registry-demo 的docker鏡像，這里先把這個鏡像運行起來。
對這條命令做個簡單說明， -d 指定當前容器運行在後台， --name 指定容器名稱， --publish 指定埠映射到宿主機， --volume 這個掛載是為了解決容器內的時區和宿主機不一致的問題，讓容器使用宿主機設置的時區，最後指定使用的docker鏡像，鏡像名稱和標簽需要根據自己的情況做修改。
運行這條命令之後， service-registry-demo 的容器就啟動了。訪問 http://宿主機IP:8000 ，打開注冊中心的頁面。
下邊啟動 add-service-demo 容器，
這條命令和上一條差不多，只是增加了一個 --link 參數， --link 指定容器間的連接，命令格式 --link 容器名:別名 ，這里連接了之前創建的名為 service-registry-demo 的容器，這里的別名和 application-docker.yml 文件中配置的 defaultZone 一致。其實就是通過別名找到了對應的容器IP，進到容器里查看 hosts 文件就明白了，其實就是加了條hosts映射。
add-service-demo 容器啟動成功之後，刷新配置中心的頁面，發現已經注冊到配置中心了。