Spring全家桶_基于SpringBoot和SpringCloud实现微服务架构

• Spring顶级框架
• SpringCloud的子项目
• 什么是微服务
• 怎么具体实现微服务
• 思考

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服务。

SpringCloud 的子项目

目前来讲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，可让你以命令行方式快速创建云组件。

什么是微服务？

微服务简介 
微服务的流行，Martin功不可没，这老头也是个奇人，特别擅长抽象概括和制造概念，我觉的这就是最牛逼的markting啊，感受这也是目前国人欠缺的能力。

先来看看传统的web开发方式，经过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式通常被称为Monolithic（比较难传神的翻译）。全部的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等全部逻辑。 
 
Monolithic比较适合小项目，优势是：

一、开发简单直接，集中式管理

二、基本不会重复开发

三、功能都在本地，没有分布式的管理开销和调用开销

它的缺点也很是明显，特别对于互联网公司来讲（不一一列举了）：

一、开发效率低：全部的开发在一个项目改代码，递交代码相互等待，代码冲突不断

二、代码维护难：代码功能耦合在一块儿，新人不知道何从下手

三、部署不灵活：构建时间长，任何小修改必须从新构建整个项目，这个过程每每很长

四、稳定性不高：一个微不足道的小问题，能够致使整个应用挂掉

五、扩展性不够：没法知足高并发状况下的业务需求

因此，如今主流的设计通常会采用Microservice Architecture，就是基于微服务的架构。简单来讲，微服务的目的是有效的拆分应用，实现敏捷开发和部署。 

用《The art of scalability》一书里提到的scale cube比较容易理解如何拆分。你看，咱们叫分库分表，别人总结成了scale cube，这就是抽象的能力啊，把复杂的东西用最简单的概念解释和总结。X轴表明运行多个负载均衡器以后运行的实例，Y轴表明将应用进一步分解为微服务 （分库），数据量大时，还能够用Z轴将服务按数据分区（分表）

怎么具体实现微服务

听上去好像都不错，具体怎么落地啊？这须要回答下面几个问题：

一、客户端如何访问这些服务？

二、服务之间如何通讯？

三、这么多服务，怎么找?

四、服务挂了怎么办？

五、客户端如何访问这些服务？

原来的Monolithic方式开发，全部的服务都是本地的，UI能够直接调用，如今按功能拆分红独立的服务，跑在独立的通常都在独立的虚拟机上的 Java进程了。客户端UI如何访问他的？后台有N个服务，前台就须要记住管理N个服务，一个服务下线/更新/升级，前台就要从新部署，这明显不服务咱们 拆分的理念，特别当前台是移动应用的时候，一般业务变化的节奏更快。另外，N个小服务的调用也是一个不小的网络开销。还有通常微服务在系统内部，一般是无 状态的，用户登陆信息和权限管理最好有一个统一的地方维护管理（OAuth）。

因此，通常在后台N个服务和UI之间通常会一个代理或者叫API Gateway，他的做用包括

一、提供统一服务入口，让微服务对前台透明

二、聚合后台的服务，节省流量，提高性能

三、提供安全，过滤，流控等API管理功能

个人理解其实这个API Gateway能够有不少广义的实现办法，能够是一个软硬一体的盒子，也能够是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的做 用是为前台（一般是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。

通常用过Taobao Open Platform的就能很容易的体会，TAO就是这个API Gateway。 
 
服务之间如何实现通讯 
由于全部的微服务都是独立的Java进程跑在独立的虚拟机上，因此服务间的通行就是IPC（inter process communication），已经有不少成熟的方案。如今基本最通用的有两种方式。这几种方式，展开来说均可以写本书，并且你们通常都比较熟悉细节了， 就不展开讲了。

一、同步调用

二、REST（JAX-RS，Spring Boot）

三、RPC（Thrift, Dubbo）

四、异步消息调用(Kafka, Notify, MetaQ) 
 
通常同步调用比较简单，一致性强，可是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个颇有意 思的话题。

通常REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要 求，只要封装了HTTP的SDK就能调用，因此相对使用的广一些。RPC也有本身的优势，传输协议更高效，安全更可控，特别在一个公司内部，若是有统一个 的开发规范和统一的服务框架时，他的开发效率优点更明显些。就看各自的技术积累实际条件，本身的选择了。

而异步消息的方式在分布式系统中有特别普遍的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能 保证调用方的服务体验，继续干本身该干的活，不至于被后台性能拖慢。

不过须要付出的代价是一致性的减弱，须要接受数据最终一致性；还有就是后台服务通常要 实现幂等性，由于消息发送出于性能的考虑通常会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如 果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。 
这么多服务怎么找 
在微服务架构中，通常每个服务都是有多个拷贝，来作负载均衡。一个服务随时可能下线，也可能应对临时访问压力增长新的服务节点。服务之间如何相互 感知？服务如何管理？这就是服务发现的问题了。

通常有两类作法，也各有优缺点。基本都是经过zookeeper等相似技术作服务注册信息的分布式管理。当 服务上线时，服务提供者将本身的服务信息注册到ZK（或相似框架），并经过心跳维持长连接，实时更新连接信息。服务调用者经过ZK寻址，根据可定制算法， 找到一个服务，还能够将服务信息缓存在本地以提升性能。当服务下线时，ZK会发通知给服务客户端。

一、客户端作：优势是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护全部调用服务的地址，有技术难度，通常大公司都有成熟的内部框架支持，好比Dubbo。

二、服务端作：优势是简单，全部服务对于前台调用方透明，通常在小公司在云服务上部署的应用采用的比较多。

 
这么多服务，服务挂了怎么办？

前面提到，Monolithic方式开发一个很大的风险是，把全部鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠 的。经过微服务拆分能下降这个风险，不过若是没有特别的保障，结局确定是噩梦。

咱们刚遇到一个线上故障就是一个很不起眼的SQL计数功能，在访问量上升 时，致使数据库load彪高，影响了所在应用的性能，从而影响全部调用这个应用服务的前台应用。因此当咱们的系统是由一系列的服务调用链组成的时候，咱们 必须确保任一环节出问题都不至于影响总体链路。相应的手段有不少：

一、重试机制

二、限流

三、熔断机制

四、负载均衡

五、降级（本地缓存）

这些方法基本上都很明确通用，就不详细说明了。 

服务的应用

这里有一个图很是好的总结微服务架构须要考虑的问题，包括

一、API Gateway

二、服务间调用

三、服务发现

四、服务容错

五、服务部署

六、数据调用 

微服务的优势和缺点（或者说挑战）同样明显。

一、优势

二、开发简单

三、技术栈灵活

四、服务独立无依赖

五、独立按需扩展

六、可用性高

七、缺点（挑战）

八、多服务运维难度

九、系统部署依赖

十、服务间通讯成本

十一、数据一致性

十二、系统集成测试

1三、重复工做

1四、性能监控

一、对于大的互联网公司，微服务架构是血液，是习惯，每家公司都有本身的套路和架构，细节有不一样，可是核心理念是通的。

二、对于通常的公司而言，实践微服务有很是大的技术挑战，因而乎才有了这么多IT供应商考虑这里的商机。微服务比较适合将来有必定的扩展复杂度，且有 很大用户增量预期的应用，说人话就是新兴的互联网公司。创业初期，不可能买大量的机器或者很贵的机器，可是又必须考虑应对成功后的巨量的用户，微服务架构 成了最好的选择。 

思考

看到上面的图，不是不以为特别的熟悉？其实咱们N年前就用的倒背如流了好很差？裤子都拖了。

其实原本所谓的微服务就是对互联网在应用技术的一个总结概括，IT厂商鼓吹全部概念无非是为了生意（business），SOA是，Cloud是，Microservice也是。下面玩笑颇有意思的归纳了这个状况（我加了第一条线，原图点击阅读原文查看） 
 
因此微服对咱们的思考我以为更多的是思惟上的，对已微服务架构，技术上不是问题，意识比工具重要。

一、按照业务 或者客户需求组织资源（这是最难的）

二、作有生命的产品，而不是项目

三、头狼战队，全栈化

四、后台服务贯彻Single Responsibility Principle

五、VM->Docker （to PE）

六、DevOps (to PE)

同时，对于开发同窗，有这么多的中间件和强大的PE支持当然是好事，咱们也须要深刻去了解这些中间件背后的原理，知其然知其因此然，设想下，若是咱们是一个小公司的CTO，离开的阿里的大环境，在有限的技术资源如何经过开源技术实施微服务？

最后，通常提到微服务都离不开DevOps和Docker，理解微服务架构是核心，devops和docker是工具，是手段。下次在抽时间再学习整理下。