【譯文】用Spring Cloud和Docker搭建微服務平臺

時間 2019-11-19

標籤譯文 spring cloud docker 搭建微服平臺欄目 Spring 简体版

原文原文鏈接

by Kenny Bastanihtml

Sunday, July 12, 2015前端

轉自：http://www.kennybastani.com/2015/07/spring-cloud-docker-microservices.htmljava

This blog series will introduce you to some of the foundational concepts of building a microservice-based platform using Spring Cloud and Docker.git

本系列文章將向你介紹一些有關使用Spring Cloud和Docker搭建微服務平臺的基本概念。程序員

What is Spring Cloud?github

Spring Cloud is a collection of tools from Pivotal that provides solutions to some of the commonly encountered patterns when building distributed systems. If you’re familiar with building applications with Spring Framework, Spring Cloud builds upon some of its common building blocks.web

Among the solutions provided by Spring Cloud, you will find tools for the following problems:redis

l Configuration managementspring

l Service discoverydocker

l Circuit breakers

l Distributed sessions

Spring Cloud是一組由Pivotal公司開發的工具集，爲搭建分佈式系統提供一些常見模式的解決方案。若是你熟悉使用Spring Framework來搭建應用程序的話，會發現，Spring Cloud是構建在它的一些經常使用構建塊的基礎上的。

在Spring Cloud提供的衆多解決方案中，你會找到可以解決以下問題的工具：

l 配置管理

l 服務發現

l 斷路器

l 分佈式會話

Spring Boot

The great part about working with Spring Cloud is that it builds on the concepts of Spring Boot.

Spring Cloud中的絕大部分，是構建在Spring Boot的概念之上的。

For those of you who are new to Spring Boot, the name of the project means exactly what it says. You get all of the best things of the Spring Framework and ecosystem of projects, tuned to perfection, with minimal configuration, all ready for production.

對於那些剛接觸Spring Boot的人來講，這個項目的名字就是它的含義。你將會獲得Spring Framework和項目生態系統最好的東西，通過最少的配置，調整到完美，作好生產前的全部準備。

Service Discovery and Intelligent Routing

服務發現和智能路由

Each service has a dedicated purpose in a microservices architecture. When building a microservices architecture on Spring Cloud, there are a few primary concerns to deal with first. The first two microservices you will want to create are the Configuration Service, and the Discovery Service.

在微服務框架下，每一個服務都只專一於一個目標。用Spring Cloud搭建微服務框架的時候，有幾個先要處理的關鍵點。首先要建立的兩個微服務是：配置服務（configuration service）和發現服務（discovery service）。

The graphic above illustrates a 4-microservice setup, with the connections between them indicating a dependency.

上面的圖片演示了一個由4個微服務組成的系統，以及他們之間的依賴關係。

The configuration service sits at the top, in yellow, and is depended on by the other microservices. The discovery service sits at the bottom, in blue, and also is depended upon by the other microservices.

在最上面的黃色標記的配置服務（configuration service），被其餘全部的微服務所依賴。最下面的藍色標記的發現服務（discovery service），一樣是被其餘全部的微服務所依賴。

In green, we have two microservices that deal with a part of the domain of the example application I will use throughout this blog series: movies and recommendations.

綠色的兩個微服務將會做爲例子，貫穿整篇文章。他們分別提供電影播放和簡介的服務。

Configuration Service

The configuration service is a vital component of any microservices architecture. Based on the twelve-factor app methodology, configurations for your microservice applications should be stored in the environment and not in the project.

配置服務（configuration service）對全部微服務框架都是一個只管重要的組件。基於「12-factor app」方法論（附2），微服務應用程序的配置信息被保存在系統環境中，而不是工程文件裏。

The configuration service is essential because it handles the configurations for all of the services through a simple point-to-point service call to retrieve those configurations. The advantages of this are multi-purpose.

配置服務（configuration service）很重要的緣由是：經過一個簡單的點對點服務調用，全部的服務就能夠經過它獲取本身的配置信息。這樣作的好處就是：多用途（一次配置多處使用）。

Let's assume that we have multiple deployment environments. If we have a staging environment and a production environment, configurations for those environments will be different. A configuration service might have a dedicated Git repository for the configurations of that environment. None of the other environments will be able to access this configuration, it is available only to the configuration service running in that environment.

假設咱們有多個部署環境。一個測試環境，一個生產環境，他們的配置信息確定是不同的。配置服務（configuration service）會有一個獨立的Git倉庫，每一個環境只會讀取本身專屬的配置信息。

When the configuration service starts up, it will reference the path to those configuration files and begin to serve them up to the microservices that request those configurations. Each microservice can have their configuration file configured to the specifics of the environment that it is running in. In doing this, the configuration is both externalized and centralized in one place that can be version-controlled and revised without having to restart a service to change a configuration.

當配置服務（configuration service）啓動以後，他會根據路徑爲其餘的微服務們提供讀取配置文件的服務。每一個微服務都擁有它正在運行的環境所使用的配置文件。實現了配置信息的外置化、集中化，並將它們置於版本控制下。這樣一來，修改配置信息也就不用重啓（配置）服務了。

With management endpoints available from Spring Cloud, you can make a configuration change in the environment and signal a refresh to the discovery service that will force all consumers to fetch the new configurations.

基於Spring Cloud對端點的管理，你能夠在修改配置信息以後，刷新發現服務（discovery service），即實現了調用者（consumers）去提取新的配置信息。

Discovery Service

The discovery service is another vital component of our microservice architecture. The discovery service handles maintaining a list of service instances that are available for work within a cluster. Within applications, service-to-service calls are made using clients. For this example project, I used Spring Cloud Feign, a client-based API for RESTful microservices that originated from the Netflix OSS project.

發現服務（discovery service）是微服務架構中另外一個必不可少的組件。它負責維護集羣裏全部正在運行中的服務實例的列表。在應用程序內部，用客戶端的方式來實現服務間的調用。這裏，我用的是Spring Cloud Feign, 一個基於RESTful客戶端的API，源自於Netflix OSS項目。

@FeignClient("movie")

public interface MovieClient {

@RequestMapping(method = RequestMethod.GET, value = "/movies")

PagedResources findAll();

@RequestMapping(method = RequestMethod.GET, value = "/movies/{id}")

Movie findById(@RequestParam("id") String id);

@RequestMapping(method = RequestMethod.POST, value = "/movies",

produces = MediaType.APPLICATION_JSON_VALUE)

void createMovie(@RequestBody Movie movie);

}

In the code example above, I am creating a Feign client that maps to the REST API methods that are exposed by the movie service. Using the @FeignClient annotation, I first specify that I want to create a client API for the movie microservice. Next I specify the mappings of the service that I want to consume. I do this by declaring a URL pattern over the methods that describes a route for a REST API.

在上面的代碼裏，我建立了一個Feign客戶端，把movie服務中暴露的接口，映射成REST API。首先，我用@FeignClient註解指明，我要建立一個針對movie微服務的客戶端API。而後，我在函數的前面，以URL的形式，具體說明了哪些是接口函數——將它們定義成了REST API的路徑。

The wonderfully easy part of creating Feign clients is that all I need to know is the ID of the service that I would like to create a client on. The URL of the service is automatically configured at runtime because each microservice in the cluster will register with the discovery service with its serviceId at startup.

要建立一個Feign客戶端，我只須要知道我要訪問的服務的ID。由於，每一個微服務的URL在發現服務（discovery service）啓動的時候，就被註冊在了各自的服務ID上。

The same is true for all other services of my microservice architecture. All I need to know is the serviceId of the service I want to communicate with, and everything else will be autowired by Spring.

在我搭建的微服務架構裏的其餘服務也都同樣的。我想要跟哪一個服務通信，只要知道它的服務ID就能夠了，其餘的事情由Spring自動裝配。

API Gateway

API 網關服務

The API gateway service is another vital component if we are going to create a cluster of services managing their own domain entities. The green hexagons below are our data-driven services that manage their own domain entities and even their own databases. By adding an API gateway service, we can create a proxy of each API route that are exposed by the green services.

若是咱們想要建立一個服務集羣來管理他們本身的域實體（注），那麼，API網關服務（API Gateway）也是一個必不可少的組件。

Let’s assume that both the recommendation service and the movie service expose their own REST API over the domain entities that they manage. The API gateway will discover these services through the discovery service and inject a proxy-based route of the API methods from the other services. In this way, both the recommendation and movie microservice will have a full definition of routes available locally from all the microservices that expose a REST API. The API Gateway will re-route the request to the service instances that own the route being requested through HTTP.

讓咱們假設剛纔介紹的兩個服務和movie服務已經經過域實體暴露了REST API。API網關服務（API Gateway）會經過發現服務（discovery service）發現這些服務，而且將它們的接口函數，從其餘服務那裏注入基於代理的路由。這樣，上面說的三個服務就具備了完整的REST API的路由（serviceID+apiUrl）。API網關服務（API Gateway）將接口調用重定向成HTTP請求到對應的服務實例上。

Example Project

實例

I’ve put together an example project that demonstrates an end-to-end cloud-native platform using Spring Cloud for building a practical microservices architecture.

Demonstrated concepts:

l Integration testing using Docker

l Polyglot persistence

l Microservice architecture

l Service discovery

l API gateway

下面，我將用一個端到端的原生雲（cloud-native）平臺系統，來演示怎樣用SpringCloud搭建真實的微服務框架。

演示中涉及的相關概念：

l 用Docker進行集成測試

l 混合持久化

l 微服務框架

l 服務發現

l API網關

Docker

Each service is built and deployed using Docker. End-to-end integration testing can be done on a developer’s machine using Docker compose.

每一個服務都是Docker編譯和部署的。開發人員在本身的開發環境就能夠用Docker實現端到端的集成測試。

Polyglot Persistence

混合持久化

One of the core concepts of this example project is how polyglot persistence can be approached in practice. Microservices in the project use their own database while integrating with the data from other services through REST or a message bus. For example, you could have a microservice for each of the following databases.

l Neo4j (graph)

l MongoDB (document)

l MySQL (relational)

例子工程裏一個核心概念，就是要探討如何實現「混合持久化」（注4）。在整合其餘服務的數據時（經過REST或是消息總線），工程中的微服務各自使用獨立的數據庫。舉個例子，每一個微服務均可以選擇下面不一樣的數據庫：
• Neo4j (圖形數據庫，注5)
• MongoDB (文檔導向型數據庫)

• MySQL (關係型數據庫)

Microservice architecture

微服務框架

This example project demonstrates how to build a new application using microservices, as opposed to a monolith-first strategy. Since each microservice in the project is a module of a single parent project, developers have the advantage of being able to run and develop with each microservice running on their local machine. Adding a new microservice is easy, as the discovery microservice will automatically discover new services running on the cluster.

例子工程演示了怎樣用微服務搭建一個應用程序，而不是採用「總體架構先行」的策略。正是由於每一個微服務都是一個「單父項目」，開發人員能夠在本機上很方便地單獨運行和開發任何一個微服務。添加一個新的微服務也很簡單，就像發現服務會自動找到集羣裏新近運行的服務同樣。

Service discovery

服務發現

This project contains two discovery services, one on Netflix Eureka, and the other uses Consul from Hashicorp. Having multiple discovery services provides the opportunity to use one (Consul) as a DNS provider for the cluster, and the other (Eureka) as a proxy-based API gateway.

本工程有兩個發現服務，一個是Netflix Eureka，另外一個是Hashicorp的Consul。用多個發現服務，是爲了實現：一個爲集羣提供DNS功能（Consul），一個做爲API網關服務（Eureka）。

API gateway

API 網關服務

Each microservice will coordinate with Eureka to retrieve API routes for the entire cluster. Using this strategy each microservice in a cluster can be load balanced and exposed through one API gateway. Each service will automatically discover and route API requests to the service that owns the route. This proxying technique is equally helpful when developing user interfaces, as the full API of the platform is available through its own host as a proxy.

每個微服務都是經過Eureka在整個集羣範圍內進行協調獲取API路由的。在此策略下，微服務間實現了負載均衡，而且向外暴露了一同個接口網關。服務會自動發現，並分配到因此求的API本身的路由上。這種代理技術在開發用戶接口的時候一樣有用，做爲平臺完整的API經過本身的主機映射爲代理服務。

Docker Demo

The example project uses Docker to build a container image of each of our microservices as a part of the Maven build process. We can easily orchestrate the full microservice cluster on our own machine using Docker compose.

例子工程用Docker爲咱們的每個微服務建立一個容器鏡像，做爲maven部署的一部分。咱們甚至能夠很輕鬆地把整個微服務集羣都部署（orchestrate編配）到咱們的開發機上。

Getting Started

開始吧

To get started, visit the GitHub repository for this example project.

在開始以前，先到GitHub資源庫上下載例子工程：

https://github.com/kbastani/spring-cloud-microservice-example

Clone or fork the project and download the repository to your machine. After downloading, you will need to use both Maven and Docker to compile and build the images locally.

把工程下載到本地以後（克隆或創建分支），你須要用Maven和Doker在本地進行編譯並生成鏡像文件。

Download Docker

下載Docker

First, download Docker if you haven’t already. Follow the instructions found here, to get Docker up and running on your development machine.

首先，若本地沒有Docker的話，要先下載。根據docs.docker.com/installation/上面的說明，獲取Docker，在開發機上運行。

You will also need to install Docker Compose, the installation guide can be found here. If you are using Mac OSX and boot2docker, make sure that you provision the boot2docker-vm on VirtualBox with at least 5GB of memory. The following command will allow you to do this.

你還須要安裝Docker Compose，安裝指導詳見docs.docker.com/compose/install/。若是你使用的是Mac OSX和boot2docker，確認好你在VirtualBox上建立的boot2docker虛擬機的內存是5GB以上。下面是設置內存的命令：

$ boot2docker init --memory=5000

Requirements

需求

The requirements for running this demo on your machine are found below.

在開發機上運行本實例的前提是已安裝以下軟件：

l Maven 3

l Java 8

l Docker

l Docker Compose

Building the project

編譯工程

To build the project, from the terminal, run the following command at the root of the project.

開始編譯：打開終端（命令行），在工程的根目錄下運行以下命令：

$ mvn clean install

The project will then download all of the needed dependencies and compile each of the project artifacts. Each service will be built, and then a Maven Docker plugin will automatically build each of the images into your local Docker registry. Docker must be running and available from the command line where you run the mvn clean install command for the build to succeed.

After the project successfully builds, you’ll see the following output:

工程將會下載全部的依賴，並依次編譯每個服務（artifacts）。編譯完以後，Maven上的Docker插件會自動將這些鏡像文件拷貝到你本地的Docker資源庫裏。在運行mvn clean install這個命令的時候，Docker必須是運行並可用的，才能保證編譯成功。成功以後，你將會看到以下輸出：

[INFO] ------------------------------------------------------------------------

[INFO] Reactor Summary:

[INFO]

[INFO] spring-cloud-microservice-example-parent .......... SUCCESS [ 0.268 s]

[INFO] users-microservice ................................ SUCCESS [ 11.929 s]

[INFO] discovery-microservice ............................ SUCCESS [ 5.640 s]

[INFO] api-gateway-microservice .......................... SUCCESS [ 5.156 s]

[INFO] recommendation-microservice ....................... SUCCESS [ 7.732 s]

[INFO] config-microservice ............................... SUCCESS [ 4.711 s]

[INFO] hystrix-dashboard ................................. SUCCESS [ 4.251 s]

[INFO] consul-microservice ............................... SUCCESS [ 6.763 s]

[INFO] movie-microservice ................................ SUCCESS [ 8.359 s]

[INFO] movies-ui ......................................... SUCCESS [ 15.833 s]

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

Start the Cluster with Docker Compose

用Docker Compose運行集羣

Now that each of the images has been built successfully, we can using Docker Compose to spin up our cluster. I’ve included a pre-configured Docker Compose yaml file with the project.

From the project root, navigate to the spring-cloud-microservice-example/docker directory.

Now, to startup the microservice cluster, run the following command:

全部的鏡像都已編譯成功，咱們能夠用Docker Compose把集羣運轉起來了。我已經在工程裏引入了一個預編譯的Docker Compose yaml文件。

從工程根目錄進入spring-cloud-microservice-example/docker目錄，運行以下命令來啓動微服務集羣：

$ docker-compose up

If everything is configured correctly, each of the container images we built earlier will be launched within their own VM container on Docker and networked for automatic service discovery. You will see a flurry of log output from each of the services as they begin their startup sequence. This might take a few minutes to complete, depending on the performance of the machine you’re running this demo on.

只要正確地配置，咱們編譯的鏡像將會在Docker容器裏啓動，發現服務自動加載到網絡上。你會在log輸出端看見一陣忙亂，是由於這些服務都在依次啓動各自的應用。這可能會持續幾分鐘，依機器的性能而定。

Once the startup sequence is completed, you can navigate to the Eureka host and see which services have registered with the discovery service.

Copy and paste the following command into the terminal where Docker can be accessed using the $DOCKER_HOST environment variable.

啓動完畢以後，你能夠登錄到Eureka服務器上，查看有哪些服務被發現服務註冊在了上面。

登錄Eureka的方法：在命令行終端運行下面的命令（保證能夠經過環境變量 $DOCKER_HOST能夠登錄Docker）：

$ open $(echo \"$(echo $DOCKER_HOST)\"|

\sed 's/tcp:\/\//http:\/\//g'|

\sed 's/[0-9]\{4,\}/8761/g'|

\sed 's/\"//g')

If Eureka correctly started up, a browser window will open to the location of the Eureka service’s dashboard, as shown below.

若是Eureka被正常啓動了，瀏覽器會打開Eureka的控制檯，以下圖所示。

We can see each of the service instances that are running and their status. We can then access one of the data-driven services, for example the movie service.

咱們能夠在上看見全部已經啓動的服務實例，以及他們的狀態。怎樣登錄一個以數據驅動的服務呢？以movie服務爲例：

$ open $(echo \"$(echo $DOCKER_HOST)/movie\"|

\sed 's/tcp:\/\//http:\/\//g'|

\sed 's/[0-9]\{4,\}/10000/g'|

\sed 's/\"//g')

This command will navigate to the API gateway’s endpoint and proxy to the movie service’s REST API endpoints. These REST APIs have been configured to use HATEOAS, which supports the auto-discovery of all of the service’s functionality as embedded links.

上面的命令會經過API網關找到movie服務的REST API。這些REST API通過配置，使用HATEOAS來支持象內嵌鏈接同樣找到服務提供的全部功能。

{

"_links" : {

"self" : {

"href" : "http://192.168.59.103:10000/movie"

"resume" : {

"href" : "http://192.168.59.103:10000/movie/resume"

"pause" : {

"href" : "http://192.168.59.103:10000/movie/pause"

"restart" : {

"href" : "http://192.168.59.103:10000/movie/restart"

"metrics" : {

"href" : "http://192.168.59.103:10000/movie/metrics"

"env" : [ {

"href" : "http://192.168.59.103:10000/movie/env"

}, {

"href" : "http://192.168.59.103:10000/movie/env"

} ],

"archaius" : {

"href" : "http://192.168.59.103:10000/movie/archaius"

"beans" : {

"href" : "http://192.168.59.103:10000/movie/beans"

"configprops" : {

"href" : "http://192.168.59.103:10000/movie/configprops"

"trace" : {

"href" : "http://192.168.59.103:10000/movie/trace"

"info" : {

"href" : "http://192.168.59.103:10000/movie/info"

"health" : {

"href" : "http://192.168.59.103:10000/movie/health"

"hystrix.stream" : {

"href" : "http://192.168.59.103:10000/movie/hystrix.stream"

"routes" : {

"href" : "http://192.168.59.103:10000/movie/routes"

"dump" : {

"href" : "http://192.168.59.103:10000/movie/dump"

"refresh" : {

"href" : "http://192.168.59.103:10000/movie/refresh"

"mappings" : {

"href" : "http://192.168.59.103:10000/movie/mappings"

"autoconfig" : {

"href" : "http://192.168.59.103:10000/movie/autoconfig"

}

Conclusion

總結

This has been the first part in a multi-part series about building microservice architectures with Spring Cloud and Docker. In this blog post, we went over the following concepts:

l Service Discovery

l Externalized Configuration

l API Gateway

l Service Orchestration with Docker Compose

本文是介紹如何使用Spring Cloud和Docker搭建微服務框架系列的第一篇。經過本文，咱們瞭解了以下幾個概念：

l 服務發現

l 配置外置化

l API網關

l 用Docker Compose編配服務

In the next blog post, we will go over how to build application front-ends that integrate with our backend services. We will also take a look at a use case for polyglot persistence, using both MySQL (relational) and Neo4j (graph).

下篇文章，咱們將會了解怎樣搭建一個前端應用，來跟本文裏的後臺服務進行整合。還會經過一個實例講講混合持久化，使用MySQL和Neo4j。

Special thanks

特別感謝

I want to give special thanks to Josh Long and the rest of the Spring team for giving me the chance to learn first-hand about the many wonderful things that the Spring Framework has to offer. Without Josh's mentorship I would not be able to put into words all of the amazing things that the Spring ecosystem has to offer.

特別感謝Josh Long以及Spring團隊的其餘成員，給我機會讓我率先學習到了Spring Framework提供的美妙功能。沒有Josh的指導，我更不可能把Spring生態系統提供功能寫出來。

Many of the great open source tools, like Spring Cloud, wouldn't be possible without the thought leadership from people like Adrian Cockcroft (Netflix OSS), Martin Fowler (everything), Sam Newman (O'Reilly's Building Microservices), Ian Robinson (consumer driven contracts), Chris Richardson (Cloud Foundry) and the many others who have helped to make the world of open source software what it is today.

沒有Adrian Cockcroft (Netflix OSS), Martin Fowler (everything), Sam Newman (O'Reilly's Building Microservices), Ian Robinson (consumer driven contracts注6), Chris Richardson (Cloud Foundry)和領導，不少像Spring Cloud這樣偉大的開源工具是不可能實現的，以及其餘一樣在開源世界裏作出貢獻的人們。

注1：Spring Cloud

（摘自：http://projects.spring.io/spring-cloud/#quick-start）

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer's own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.

Spring Cloud提供了一系列工具，以使開發者可以在分佈式系統上快速搭建起經常使用的功能。好比說：配置管理、服務發現、斷路器、智能路由、微代理、控制總線、one-time tokens、全局鎖、leadership election、分佈式會話、集羣狀態。分佈式系統的協調致使了樣板模式（boiler plate patterns），而且使用Spring Cloud開發人員能夠快速地搭建起實現這些模式的服務和應用程序。

注2：一句話歸納下spring框架及spring cloud框架主要組件

（轉自：http://www.cnblogs.com/skyblog/p/5073843.html）

spring 頂級項目：

Spring IO platform:用於系統部署，是可集成的，構建現代化應用的版本平臺，具體來講當你使用maven dependency引入spring jar包時它就在工做了。

Spring Boot:旨在簡化建立產品級的 Spring 應用和服務，簡化了配置文件，使用嵌入式web服務器，含有諸多開箱即用微服務功能，能夠和spring cloud聯合部署。

Spring Framework:即一般所說的spring 框架，是一個開源的Java/Java EE全功能棧應用程序框架，其它spring項目如spring boot也依賴於此框架。

Spring Cloud：微服務工具包，爲開發者提供了在分佈式系統的配置管理、服務發現、斷路器、智能路由、微代理、控制總線等開發工具包。

Spring XD：是一種運行時環境（服務器軟件，非開發框架），組合spring技術，如spring batch、spring boot、spring data，採集大數據並處理。

Spring Data：是一個數據訪問及操做的工具包，封裝了不少種數據及數據庫的訪問相關技術，包括：jdbc、Redis、MongoDB、Neo4j等。

Spring Batch：批處理框架，或者說是批量任務執行管理器，功能包括任務調度、日誌記錄/跟蹤等。

Spring Security：是一個可以爲基於Spring的企業應用系統提供聲明式的安全訪問控制解決方案的安全框架。

Spring Integration：面向企業應用集成（EAI/ESB）的編程框架，支持的通訊方式包括HTTP、FTP、TCP/UDP、JMS、RabbitMQ、Email等。

Spring Social：一組工具包，一組鏈接社交服務API，如Twitter、Facebook、LinkedIn、GitHub等，有幾十個。

Spring AMQP：消息隊列操做的工具包，主要是封裝了RabbitMQ的操做。

Spring HATEOAS：是一個用於支持實現超文本驅動的 REST Web 服務的開發庫。

Spring Mobile：是Spring MVC的擴展，用來簡化手機上的Web應用開發。

Spring for Android：是Spring框架的一個擴展，其主要目的在於簡化Android本地應用的開發，提供RestTemplate來訪問Rest服務。

Spring Web Flow：目標是成爲管理Web應用頁面流程的最佳方案，將頁面跳轉流程單獨管理，並可配置。

Spring LDAP：是一個用於操做LDAP的Java工具包，基於Spring的JdbcTemplate模式，簡化LDAP訪問。

Spring Session：session管理的開發工具包，讓你能夠把session保存到redis等，進行集羣化session管理。

Spring Web Services：是基於Spring的Web服務框架，提供SOAP服務開發，容許經過多種方式建立Web服務。

Spring Shell：提供交互式的Shell可以讓你使用簡單的基於Spring的編程模型來開發命令，好比Spring Roo命令。

Spring Roo：是一種Spring開發的輔助工具，使用命令行操做來生成自動化項目，操做很是相似於Rails。

Spring Scala：爲Scala語言編程提供的spring框架的封裝（新的編程語言，Java平臺的Scala於2003年末/2004年初發布）。

Spring BlazeDS Integration：一個開發RIA工具包，能夠集成Adobe Flex、BlazeDS、Spring以及Java技術建立RIA。

Spring Loaded：用於實現java程序和web應用的熱部署的開源工具。

Spring REST Shell：能夠調用Rest服務的命令行工具，敲命令行操做Rest服務。

目前來講spring主要集中於spring boot（用於開發微服務）和spring cloud相關框架的開發，spring cloud子項目包括：

Spring Cloud Config：配置管理開發工具包，可讓你把配置放到遠程服務器，目前支持本地存儲、Git以及Subversion。

Spring Cloud Bus：事件、消息總線，用於在集羣（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。

Spring Cloud Netflix：針對多種Netflix組件提供的開發工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。

Netflix Eureka：雲端負載均衡，一個基於 REST 的服務，用於定位服務，以實現雲端的負載均衡和中間層服務器的故障轉移。

Netflix Hystrix：容錯管理工具，旨在經過控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。

Netflix Zuul：邊緣服務工具，是提供動態路由，監控，彈性，安全等的邊緣服務。

Netflix Archaius：配置管理API，包含一系列配置管理API，提供動態類型化屬性、線程安全配置操做、輪詢框架、回調機制等功能。

Spring Cloud for Cloud Foundry：經過Oauth2協議綁定服務到CloudFoundry，CloudFoundry是VMware推出的開源PaaS雲平臺。

Spring Cloud Sleuth：日誌收集工具包，封裝了Dapper,Zipkin和HTrace操做。

Spring Cloud Data Flow：大數據操做工具，經過命令行方式操做數據流。

Spring Cloud Security：安全工具包，爲你的應用程序添加安全控制，主要是指OAuth2。

Spring Cloud Consul：封裝了Consul操做，consul是一個服務發現與配置工具，與Docker容器能夠無縫集成。

Spring Cloud Zookeeper：操做Zookeeper的工具包，用於使用zookeeper方式的服務註冊和發現。

Spring Cloud Stream：數據流操做開發包，封裝了與Redis,Rabbit、Kafka等發送接收消息。

Spring Cloud CLI：基於 Spring Boot CLI，可讓你以命令行方式快速創建雲組件。

注3：twelve-factor app methodology

（摘自：https://www.sitepoint.com/12-factor-apps-methodology-implement-apps-appfog/）

As made apparent by the title, the 12-Factor App methodology is a list of principles, each explaining the ideal way to handle a subset of your application. The 12 factors are as follows:

1. Codebase – One codebase tracked in revision control, many deploys

The first principle of the 12-Factor App methodology is related to your application’s codebase. The most important point here is to ensure that your application is tracked with revision control, and that it sits in a central repository that is accessible to your developers. This is most commonly handled by using Git or SVN to store your code.

2. Dependencies – Explicitly declare and isolate dependencies

There is no room for assumptions when it comes to dependencies. Anything your applications rely on to run should be controlled and managed to minimize — if not completely eliminate — conflicts.

3. Configuration – Store config in the environment

Configuration, as it relates to API keys, services, and database credentials, should never be hardcoded. This prevents your application from being at risk from both production data leaks and production errors. Instead of hardcoding this information, rely on environment variables to handle this sensitive information.

4. Backing Services – Treat backing services as attached resources

A backing service is one that requires a network connection to run. This is a very popular paradigm found in modern application development, especially prevalent with the rise in popularity of microservice architecture. The 12-Factor App methodology advises developers to treat these services agnostically, meaning changes or modifications should occur without having to make any code changes. Typically, this factor is best handled by calling each backing service through an API, with credentials stored in a configuration file that lives in your runtime environment.

5. Build, release, run – Strictly separate build and run stages

Build, release, and run stages should be treated as completely distinct from one another. Automation and tooling will help to make this principle simpler.

This can be accomplished by using existing tools to fully automate your build process. A tool like Github can be used to tag your latest build, while Jenkins can be used to automate your release stage.

6. Processes – Execute the app as one or more stateless processes

Stateless applications are designed to degrade gracefully. That means if a dependency fails, the app itself does not become a failure. Single points of failure may be difficult, but not impossible, to avoid. The 12-Factor App methodology recommends storing data outside of running code in order to prevent operational headaches and debugging nightmares.

7. Port binding – Export services via port binding

All application services should be accessible via a URL. For web applications, this process happens automatically. This enables 12-Factor Apps to be fully self-contained, avoiding the need to rely on various methods of runtime injection in order to create web facing services.

8. Concurrency – Scale out via the process model

Every process inside your application should be treated as a first-class citizen. That means that each process should be able to scale, restart, or clone itself when needed. This approach will improve the sustainability and scalability of your application as a whole.

9. Disposability – Maximize robustness with fast startup and graceful shutdown

As noted in the previous factor, treating processes as first-class citizens translates to an easier startup and shutdown process. Compare this to an application where all process are bundled together, where startup and shutdown processes can take up to several minutes depending on their size. To ensure your startup and shutdown processes remain seamless, reach for tried and true services that are optimized for speed and performance. Databases and caches like RabbitMQ, Redis, Memcached, and CenturyLink’s own Orchestrate are just a few services that are built to help with this factor.

10. Dev/prod Parity – Keep development, staging, and production as similar as possible

Consistency is key for meeting this factor. When your environments are similar, testing and developing gets much simpler. Similar environments means ensuring that areas such as your infrastructure stack, config management processes, software and runtime versions and deployment tools are the same everywhere. With this approach, fewer bugs will find their way into your production environment, since your test cases can be applied on production-level data.

11. Logs – Treat logs as event streams

Logging is important for debugging and checking up on the general health of your application. At the same time, your application shouldn’t concern itself with the storage of this information. Instead, these logs should be treated as a continuous stream that is captured and stored by a separate service.

12. Admin processes – Run admin/management tasks as one-off processes

One-off admin processes are essentially data collection jobs that are used to gather key information about your application. This information will be needed to asses the state of your production environment, so it’s important to ensure these one-off processes occur in your production environment. That way there can be no discrepancies between the data you need and the data coming from the visible long running production application.

簡介

（偷個懶兒，從網上摘箇中文的）

現在，軟件一般會做爲一種服務來交付，它們被稱爲網絡應用程序，或軟件即服務（SaaS）。12-Factor 爲構建以下的 SaaS 應用提供了方法論：

l 使用標準化流程自動配置，從而使新的開發者花費最少的學習成本加入這個項目。

l 和操做系統之間儘量的劃清界限，在各個系統中提供最大的可移植性。

l 適合部署在現代的雲計算平臺，從而在服務器和系統管理方面節省資源。

l 將開發環境和生產環境的差別降至最低，並使用持續交付實施敏捷開發。

l 能夠在工具、架構和開發流程不發生明顯變化的前提下實現擴展。

這套理論適用於任意語言和後端服務（數據庫、消息隊列、緩存等）開發的應用程序。

12-Factor:

I. 基準代碼

一份基準代碼，多份部署

II. 依賴

顯式聲明依賴關係

III. 配置

在環境中存儲配置

IV. 後端服務

把後端服務看成附加資源

V. 構建，發佈，運行

嚴格分離構建和運行

VI. 進程

以一個或多個無狀態進程運行應用

VII. 端口綁定

經過端口綁定提供服務

VIII. 併發

經過進程模型進行擴展

IX. 易處理

快速啓動和優雅終止可最大化健壯性

X. 開發環境與線上環境等價

儘量的保持開發，預發佈，線上環境相同

XI. 日誌

把日誌看成事件流

XII. 管理進程

後臺管理任務看成一次性進程運行

注4：混合持久化

（摘自：http://www.cnblogs.com/leetieniu2014/p/5153967.html）

數據庫環境在過去的十多年裏增加巨大。每一個新的數據庫相較於其它數據庫，有着某些優點，可是它們作了某種折衷。

事實上，CAP定理【注2】告訴咱們，不可能擁有完美的數據庫，咱們須要根據應用程序來選擇哪一種折衷是可接受的。

帶有這些約束的工做場景符合Martin Fowler推廣的混合持久化思路。混合持久化的思路是指，你應該根據工做選擇合適的數據庫，這樣咱們就能二者兼得了。

咱們的數據庫客戶端應該這樣作，它應該可以與不少不一樣的數據庫交流。在代碼層面看起來是這樣的：

Client(mongo(details)).put(key, value);

Client(redis(details)).get(key);

注5：Neo4j簡介

Neo4j是一個高性能的,NOSQL圖形數據庫，它將結構化數據存儲在網絡上而不是表中。Neo4j也能夠被看做是一個高性能的圖引擎，該引擎具備成熟數據庫的全部特性。程序員工做在一個面向對象的、靈活的網絡結構下而不是嚴格、靜態的表中——可是他們能夠享受到具有徹底的事務特性、企業級的數據庫的全部好處。

Neo4j因其嵌入式、高性能、輕量級等優點，愈來愈受到關注。

注6：Consumer-Driven Contract

（摘自：http://servicedesignpatterns.com/WebServiceEvolution/ConsumerDrivenContracts）

The Consumer-Driven Contract pattern helps service owners create service APIs that reflect client needs; it also helps service owners evolve services without breaking existing clients. Service owners receive integration tests from each client and incorporate these tests into the service's test suite. The set of integration tests received from all existing clients represents the service's aggregate obligations with respect to its client base. The service owner is then free to change and evolve the service just so long as the existing integration tests continue to pass.

「消費者驅動的契約」模式，幫助服務的提供者可以開發出反應客戶端需求的API；它還幫助服務提供者在不須要關閉客戶端的狀況下升級服務程序。服務提供者接收來自客戶端的集成測試，並將這些測試結果整合進測試套件裏。這樣一組來自現存客戶端的集成測試報告，反應出了在客戶端層面的集中反饋。隨着集成測試的進行，服務提供者就能夠自由地修改和升級服務端程序。

生詞：

encounter 遭遇

pattern 模式，模板

circuit 迴路

circuit breaker 斷路器

ecosystem 生態系統

tune 調整

perfect 完美的

intelligent 聰明的，智能

illustrate （用圖解等）說明

recommend 介紹，建議

methodology （從事某一活動的）方法