一篇没有什么实质内容的文章，不过试图从比较笼统，立足点比较高的角度去解释Spring项目和微服务，以及两者的关系。

Spring 顶级项目

打开 spring ​​官网​​即可看到目前在大力开发的顶级项目：

• Spring Boot：旨在简化创建产品级的 Spring 应用和服务，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用微服务功能，可以和spring cloud联合部署。
• Spring Framework：即通常所说的spring 框架，是一个开源的Java/Java EE全功能栈应用程序框架，其它spring项目如spring boot也依赖于此框架。
• Spring Cloud Data Flow：
• Spring Cloud：微服务工具包，为开发者提供了在分布式系统的配置管理、服务发现、断路器、智能路由、微代理、控制总线等开发工具包。
• Spring Data：是一个数据访问及操作的工具包，封装很多种数据及数据库的访问相关技术，包括：jdbc、Redis、MongoDB、Neo4j等。
• Spring Integration：面向企业应用集成（EAI/ESB）的编程框架，支持的通信方式包括HTTP、FTP、TCP/UDP、JMS、RabbitMQ、Email等。
• Spring Batch：批处理框架，或说是批量任务执行管理器，功能包括任务调度、日志记录/跟踪等。
• Spring Security：为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。
• Spring HATEOAS：是一个用于支持实现超文本驱动的 REST Web 服务的开发库。
• Spring Rest Docs：Spring REST Docs 帮助你管理 RESTful 服务文档，使用 Asciidoctor 来编写文档，使用 Spring MVC Test 自动生成片段。
• Spring AMQP：消息队列操作的工具包，主要是封装RabbitMQ的操作。
• Spring Mobile：是Spring MVC的扩展，用来简化手机上的Web应用开发。
• Spring for Android：其主要目的在乎简化Android本地应用的开发，提供RestTemplate来访问Rest服务。
• Spring Web Flow：目标是成为管理Web应用页面流程的最佳方案，将页面跳转流程单独管理，并可配置。
• Spring Web Services：是基于Spring的Web服务框架，提供SOAP服务开发，允许通过多种方式创建Web服务。
• Spring LDAP：是一个用于操作LDAP的Java工具包，基于Spring的JdbcTemplate模式，简化LDAP访问。
• Spring Session：session管理的开发工具包，让你可以把session保存到redis等，进行集群化session管理。
• Spring Shell：提供交互式的Shell可让你使用简单的基于Spring的编程模型来开发命令，比如Spring Roo命令。
• Spring FLO：
• Spring Kafka：
• Spring statemachine：
• Spring IO platform：用于系统部署，是可集成的，构建现代化应用的版本平台，具体来说当你使用maven dependency引入spring jar包时它就在工作。

社区项目：

• Spring Roo：是一种Spring开发的辅助工具，使用命令行操作来生成自动化项目，操作非常类似于Rails。
• Spring Scala：为Scala语言编程提供的spring框架的封装（新的编程语言，Java平台的Scala于2003年底/2004年初发布）。

以及projects in the Attic：

• Spring BlazeDS Integration：一个开发RIA工具包，可以集成Adobe Flex、BlazeDS、Spring以及Java技术创建RIA。
• Spring Loaded：用于实现java程序和web应用的热部署的开源工具。
• Spring REST Shell：可以调用Rest服务的命令行工具，敲命令行操作Rest服务。
• Spring XD：是一种运行时环境（服务器软件，非开发框架），组合spring技术，如spring batch、spring boot、spring data，采集大数据并处理。
• Spring Social：一组工具包，一组连接社交服务API，如Twitter、Facebook、LinkedIn、GitHub等，有几十个。
  参考​​​官网​​

spring boot

• 约定大于配置；
• 自动配置；
• 众多starter，甚至可以自定义starter；

Spring Cloud

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 centers, and managed platforms such as Cloud Foundry.

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化分布式系统基础设施的开发，如服务发现与注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉复杂的配置和实现原理，最终给开发者一套简单易懂、易部署和易维护的分布式系统开发工具包。

• Spring Cloud Config：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。
• Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。Spring Cloud Bus是将分布式节点用轻量的消息代理连接起来，支持服务之间或者广播通信。同时，消息总线可以为微服务做监控。比如，当我们修改并提交配置文件时，会通过Bus分发广播消息，从而自动出发对应服务的Refresh；目前Spring Cloud Bus已经支持 Kafka 和 RabbitMQ。
• Spring Cloud Netflix：针对多种 Netflix 组件提供的开发工具包，包括Eureka、Hystrix、Zuul、Archaius等。
• Spring Cloud Eureka：云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。
• Spring Cloud Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。
• Spring Cloud Ribbon：提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。
• Spring Cloud Zuul：Zuul 是在云平台上提供动态路由、监控、弹性、安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。
• Spring Cloud Feign：Feign是一种声明式、模板化的HTTP客户端；
• Spring Cloud Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
• Spring Cloud Consul：封装Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
• Spring Cloud for Cloud Foundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。
• Spring Cloud Cloud Foundry Service Broker 为建立管理云托管服务的服务代理提供一个起点。
• Spring Cloud Sleuth：日志收集工具包，封装Dapper和log-based追踪以及Zipkin和HTrace操作，为SpringCloud应用提供一种分布式追踪解决方案。
• Spring Cloud Data Flow：大数据操作工具，SpringXD重构而成，作为Spring XD的替代产品，它是一个混合计算模型，结合流数据与批量数据的处理方式，大数据操作工具，通过命令行方式操作数据流。是运行时原生云端分布式服务编排服务，可以开发和执行大范围数据处理包括ETL，实时处理，流处理，批处理，数据导入导出，持续计算和编排数据通道（Data Pipelines）的统一编程模型和托管服务。支持DSL，REST、支持UT、支持run as Maven或者Docker、支持 YARN、Mesos、kubernetes；
• Spring Cloud Security：基于spring security的安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。
• Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服务发现和配置管理。
• Spring Cloud Stream：数据流操作开发包，封装与Redis,Rabbit、Kafka等发送接收消息。轻量级事件驱动框架，对于分布式数据流封装，支持与Redis, Rabbit, Kafka等发送接受消息，分布式服务则可以pub／sub，定义分组／分区。具体程序中则引入简单的注解@EnableBinding，并通过@StreamListener来处理事件流。
• Spring Cloud CLI：基于 Spring Boot CLI，让你以命令行方式快速建立云组件。
• Spring Cloud Turbine：Turbine是聚合服务器发送事件流数据的一个工具，用来监控集群下hystrix的metrics情况。
• Spring Cloud Task：提供云端计划任务管理、任务调度，短生命周期的微服务，为Spring Boot 应用简单声明添加功能和非功能特性。
• Spring Cloud Connectors：便于云端应用程序在各种PaaS平台连接到后端，如：数据库和消息代理服务。
• Spring Cloud Cluster：提供 Leadership 选举接口，支持实现框架如：Zookeeper、Redis、Hazelcast、Consul 等常见状态模式的抽象和实现。此外也提供分布式集群状态一致性，全局锁，tokens等抽象。
• Spring Cloud Starters：Spring Boot式的启动项目，为Spring Cloud提供开箱即用的依赖管理。项目已经终止并且在Angel.SR2后的版本和其他项目合并。
• Spring Cloud for AWS，使用Spring的API／语法与 AWS 集成交互；

题外话：Pivotal 是一家很牛逼的公司，获得EMC，VMware和通用电气(GE)的联合投资，Pivotal Cloud Foundry 和 VMware Photon Platform 合并成单个集成式解决方案Cloud Foundry。

spring cloud v.s. dubbo

Dubbo 是阿里开源的高性能分布式服务框架，致力于提供透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案，使得应用可通过高性能 RPC 实现服务的输出、输入功能和 Spring 框架无缝集成；包含远程通讯、集群容错和自动发现三个核心部分；实现服务治理，包括服务注册，发现，调度，监控，治理等核心，支持注册中心对等集群，缓存服务，提供高可用与健壮性。大多数场景使用长连接小数据量的模式提供服务使用。
提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何 API 侵入。同时具备软负载均衡及容错机制，可在内网替代 F5 等硬件负载均衡器，降低成本，减少单点。可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的 IP 地址，并且能够平滑添加或删除服务提供者。
Dubbo 核心功能：

• 远程通讯，提供对多种基于长连接的 NIO 框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
• 集群容错，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
• 自动发现，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo 的功能只是 Spring Cloud 体系的一部分。Dubbo 是 SOA 时代的产物，它的关注点主要在于服务调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托Spring、Spring Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spring Cloud 是一个生态。
仅关注于服务治理的这个层面，Dubbo 优于 Spring Cloud：

• Dubbo 支持更多的协议，如：rmi、hessian、http、webservice、thrift、memcached、redis 等。
  Dubbo 使用 RPC 协议效率更高，在极端压力测试下，Dubbo 的效率会高于 Spring Cloud 效率一倍多。
• Dubbo 有更强大的后台管理，Dubbo 提供的后台管理 Dubbo Admin 功能强大，提供路由规则、动态配置、访问控制、权重调节、均衡负载等诸多强大的功能。
• 可以限制某个 IP 流量的访问权限，设置不同服务器分发不同的流量权重，并且支持多种算法，利用这些功能可以在线上做服务治理、灰度发布、故障转移、流量分发等，Spring Cloud 到现在还不支持灰度发布、流量权重等功能。

微服务

定义

对于微服务的定义，每个人都有其理解。其中比较符合我的理解的有：

The micro-service architectural style is an approach to developing a single application as a suite[音似sweet] of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deploy-able by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data storage technologies. ——Martin Fowler and James Lewis

在我的心理模型中，我认为微服务是自包含（如容器）的轻量进程，他们通过HTTP进行通信，用相对较小的工作量与仪式来创建和部署，将只集中在有限领域的API提供给他们的使用者。——Tony Pujals

可以看出的关键点：

1. 一些列的独立的服务共同组成系统
2. 单独部署，跑在自己的进程里
3. 每个服务为独立的业务开发
4. 分布式的管理

虽然每个人对微服务都可以有自己的理解，不过大概的标准还是有一些的：

• 分布式服务组成的系统
• 按照业务而不是技术来划分组织
• 做有生命的产品而不是项目
• Smart endpoints and dumb pipes（强服务个体和弱通信）
• 自动化运维（DevOps）
• 容错
• 快速演化

单体架构

提到微服务，言必提单体架构 Monolithic，即所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss）里，包含DO/DAO，Service，UI等所有逻辑。
Monolithic比较适合小项目，优点：

• 开发简单直接，集中式管理
• 基本不会重复开发
• 功能都在本地，没有分布式的管理开销和调用开销

缺点：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
• 代码维护难：代码功能耦合在一起，新人不知道何从下手
• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
• 扩展性不够：无法满足高并发情况下的业务需求
• 还有很多……

SOA

提到微服务，另一个经常拿来对比的名词是SOA(Service Oriented Architect)。

SOA v.s 微服务

优缺点

微服务是一种架构风格，组件的另一种模式或实现，一个大型的系统由多个微服务组成，每个微服务可以独立部署，并且微服务间是松耦合。其中每个微服务理想情况，完成一个小的业务能力。微服务架构是以专注于单一职责的小型功能模块为子服务，一个后台服务通过RPC相互通信，去中心化，松耦合化完成复杂业务系统的设计思想。
微服务框架核心要解决或者基础设施必须要做到RPC，服务注册与发现，负载均衡，分布式配置，服务熔断机制和服务网关路由几个核心要素。
优势：

1. 分解巨大单体应用为多个微服务，解决了单体应用的复杂性问题。每个服务都有一个定义清楚的边界，通过 RPC- 或者消息驱动API与外接沟通，这样单个微服务相比单体应用更容易开发和维护。
2. 微服务架构使得每个服务都可以由专门的开发团队来开发。开发者可以自由选择开发技术，同时也意味着开发者不需要被迫使用旧项目采用的过时技术。即使重写单个微服务也不会太困难，相比重写整个单体应用容易多了。
3. 微服务架构使得每个微服务独立部署，开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度，使得持续化部署成为可能。
4. 微服务架构使得每个服务可以独立扩展。

简而言之，就是开发简单，技术栈灵活，服务独立无依赖，独立按需扩展，可用性高。

劣势：

1. 微服务应用是分布式系统，由此会带来固有的复杂性。开发者不得不使用 RPC 或者消息传递，来实现进程间通信；此外，必须要写代码来处理消息传递中速度过慢或者服务不可用等局部失效问题。
2. 另外一个关于微服务的挑战来自于分区的数据库架构，同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库，从而对开发者提出了更高的要求和挑战。
3. 测试一个基于微服务架构的应用也是很复杂的任务。比如，对于采用流行的 Spring Boot 架构的单体式 web 应用，测试它的 REST API，是很容易的事情。但对于微服务架构，同样的服务测试需要启动与它有关的所有服务。
4. 服务模块间的依赖。应用的升级有可能会波及多个服务模块的修改。在单体应用中，只需要修改相关模块，整合变化，一并部署就好了。微服务架构模式就需要考虑服务间的依赖关系，按照依赖关系依次部署。
5. 部署复杂，一个微服务应用一般由大批服务构成。每个服务都有多个实例，这就形成大量需要配置、部署、扩展和监控的部分。除此之外，还需要完成一个服务发现机制，以用来发现服务的通信地址和端口。

总结起来，带来维护，部署，版本控制，运营，性能监控，DevOps，分布式事务，数据一致性，服务间通信成本，系统集成测试等一些列挑战；

拆分

微服务的核心在于定义领域模型的边界，在于拆分服务；单体结构的拆分，绝不是一个容易的活。系统的拆分也是和业务强耦合的，需要业务架构师对于业务非常熟悉。
服务拆分的原则：

• 横向拆分。按照不同的业务进行拆分，如：订单、营销、风控、积分资源等。
• 纵向拆分。把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务，下沉到底层，形成相对独立的原子服务层。这样一纵一横，就可以实现业务的服务化拆分。

康威定律：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。
单一职责原则

拆分的目的可以说是分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
微服务的拆分力度需与具体业务相结合，总的原则是服务内部高内聚，服务之间低耦合。

软件发布
系统中经常变动的部分大约只占 20%，剩下的 80% 基本不变或极少变化，因此软件的发布周期完全不同。可以把不变的 80% 分离出来，单独部署，单独管理。这不仅有利于降低系统的复杂性，精简团队的规模，也有利于在系统发生故障的时候快速定位。如果不做这种拆分，系统在扩展的过程会浪费很多资源。

投入产出
衡量拆分收益的标准是拆分后的维护成本要低过拆分前的维护成本，也就是说不能因为拆分而带来更大的维护工作。
拆分前的维护成本 - 拆分后的维护成本 ≧ 0
服务的维护成本包括维护该服务所需要耗费的人力、物力和时间。如果一个系统拆分成两个或两个以上，导致所有的资源都加倍，那将会很失败。最好的结果是原来维护服务的同一套人马分成两个部分，因为拆分后服务的复杂性降低，所需要的维护资源显著减少，或者对人员能力的要求大大降低。

提到微服务离不开 DevOps和Docker，理解微服务架构是核心，devops和docker是实现工具/手段。