Spring Cloud搭建微服務架構----前言

前言

每一個微服務都是六邊形應用，都有本身的業務邏輯和適配器。服務之間經過API互相通訊，提供接口供客戶端使用。每一個實例多是一個雲VM或者是Docker容器。

以前的web應用拆分紅一系列簡單的服務應用。拆分以後能夠對不一樣用戶，不一樣設備，不一樣場景進行自行部署。

微服務之間經過REST API或者MQ異步方式通訊，供外網使用的API，經過Gateway來傳遞信息。

微服務的拆分，不像傳統多個服務共享一個數據庫，微服務架構每一個服務都有本身的數據庫，每種服務均可以有本身適合的數據庫類型。

微服務好處

1. 分解了單體應用提供多個服務的複雜性問題，拆分以後每一個服務都有一個用RPC或是MQ或是API定義的邊界。因爲傳統單體應用沒有清晰的邊界，存在開發，理解，維護，部署的複雜問題；
2. 每一個服務均可以有單獨的團隊維護開發，開發者客戶選擇本身擅長和合適的技術；
3. 每一個服務均可以獨立部署，開發者不須要協調因其餘服務調用，部署對本服務的影響。加快部署速度，更好的執行AB測試。持續部署變爲可能。
4. 每一個服務均可以獨立擴展。

微服務不足

1. 須要考慮和關心更多服務之間調用的問題。
2. 須要考慮多個服務的編排和依賴關係，包括開發和部署。
3. 多個服務的配置，部署，擴展，監控。

微服務的特徵

1. 每一個服務僅僅對單個業務負責，這個業務也是這個服務的完整容量；
2. 每一個微服務均可以獨立部署，不需依賴其餘服務的相關資源，如數據庫，內存緩存等；
3. 輕量級的通訊協議，如REST，AMQP等；
4. 服務具備可代替性，每一個服務原則上均可以被不一樣的開發語言，開發框架進行技術實現，替換後不影響原有微服務對外提供的功能；
5. 每一個服務擁有本身獨立的數據存儲；
6. 每一個微服務由小的團隊維護，服務以業務單元進行拆分；
7. 服務之間可經過組成聚合服務對外提供較粗粒度的服務功能；

微服務名詞

• Gateway：爲客戶端提供API管理功能，負責負載均衡，緩存，訪問控制，API計費監控等任務，可經過Eureka或者NGINX實現；
• 服務註冊於發現模塊；
• 斷路器；

微服務選型

• Dubbo，DubboX（再也不維護）；
• Spring Cloud（集成框架）；
• Motan（微博平臺）；
• Thrift，gRPC（算不上框架）；

本次主要使用Spring Cloud；

基礎框架選擇 Spring Cloud和Dubbo：

• Dubbo： 國內影響力較大，實現了服務治理的基礎，可是完成一個完備的微服務架構，還須要在各環節去擴展和完善以保證集羣健康，文檔較穩定。
• Spring Cloud： 國外影響大，社區活躍度領先，將成熟框架融爲一體，繼承了Spring Boot的簡單配置，快速開發，部署輕鬆特色，更新較快，文檔有差別。

日誌監控

由Docker經過Syslog日誌驅動將日誌寫入Logstash，參照ELK解決方案。

Devops

使用Docker做爲微服務交付標準組件。

集成Docker

經過Consul集成Docker。