微服务架构介绍
微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。
微服务架构是一种软件架构模式，将单一应用程序划分成一个个小的服务，服务之间互相调用、或者通过网关调用运行。每个服务运行在其独立的系统进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的Rest API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到各个软件环境等。
微服务场景
在传统型应用系统中, 虽然区分业务模块与基础模块,但是不能做到每个服务独立运行与部署. 那么在后台将是一个统一的服务体，对外提供服务.在用户访问前端使用负载均衡进行4-7的负载. 后台采用缓存、数据库、共享存储进行数据的共享. 在业务代码更新过程中， 不可避免的会影响到其他业务的系统。 而在上线之前，一般都会经历测试的阶段, 但是在业务系统庞大之后，不论每次软件版本功能的更新大与小，测试都是无法全面测试的。有时候甚至是在当时上线没有发现问题，可能会在下次发布或者是在其他的操作过程中，才发现问题。这样处理问题的故障定位就会异常的复杂，不能快速准确的定位问题.
微服务模式
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上这种架构类型是移动互联网现在最流行的软件开发框架。在微服务架构中，集中式业务服务管理几乎不存在，微服务使用轻量级HTTP接口进行通信。
在SOA 架构发展之后，相比Micro Service 能够基于框架快速的开发应用程序, 甚至都不需要专用的启动web 服务, 来启动微服务. 而自身的软件框架已经携带。
在各个软件运行环境中（测试、开发、生产），运维与开发人员经常需要修改不同环境的配置文件, 在操作中可能会因为失误导致服务异常的情况，经常发生. 之前的SOA架构如果需要实现配置中心功能，那么需要借助第三方的配置中心, 但是这一切相对于微服务而言，实现起来比较简单，包括一系列的服务治理(服务管理手段)方案，在框架中早已经集成，大大降低了开发人员的工作负载，使得软件开发人员只需要专注于业务逻辑开发，而不需要关心软件框架的内部实现。
在后期的容器云中，客户端使用http协议的方式，使得微服务框架能够非常方便的融入docker.并且通过docker 的ingress 功能实现对服务的弹性负载均衡.
微服务的优点和缺点
优点
优势复杂度可控(复杂度降低) 在将业务应用拆分之后，使原本复杂的应用，变得简单。每一个微服务只有单一的某一项功能，并通过定义良好的接口调用模式，使客户端调用更加简单。由于”体积”小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
缺点
为什么需要微服务
单体应用特点
大部分的开发者经历和开发过单体应用，无论是传统的 Servlet JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么长期陪伴我们的单体应用有什么弊端？我们是面临了什么问题，导致我们要抛弃单体应用转向微服务架构？主要原因如下：
- 部署成本高（无论是修改1行代码，还是10行代码，都要全量替换）。
- 改动影响大，风险高（不论代码改动多小，成本都相同）。
- 因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）。
- 无法满足快速扩容，弹性伸缩，无法适应云环境特性等问题。
微服务特点
微服务架构的特点：针对特定服务发布，影响小，风险小，成本低；频繁发布版本，快速交付需求；低成本扩容，弹性伸缩，适应云环境。 我们知道一个朴素的理念，没有任何事物是完美的，任何东西都有两面性，有得必有失，那么在选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给我们带来了什么问题？简单总结如下：
分布式系统的复杂性
部署，测试和监控的成本问题
分布式事务和CAP的相关问题
系统应用由原来的单体变成几十到几百个不同的工程，会所产生例如包括服务间的依赖，服务如何拆封，内部接口规范，数据传递等等问题，尤其是服务拆分，需要团队熟悉业务流程，懂得取舍，要保证拆分的粒度服务既符合“高内聚，低耦合”的基本原则，还要兼顾业务的发展以及公司的愿景，要还要说服团队成员为之努力，并且积极投入，在多方中间取得平衡。
对于分布式系统，部署，测试和监控都需要大量的中间件来支撑，而且中间件本身也要维护，原先单体应用很简单的事务问题 ，转到分布式环境就变得很复杂，分布式事务是采用简单的重试 补偿机制，还是采用二阶段提交协议等强一致性方法来解决，就要取决对业务场景的熟悉加上反复的权衡了，相同问题还包括对 CAP 模型的权衡，总之微服务对团队整体的技术栈水平整体要求更高
应用架构变迁图
微服务架构与RPC框架对比
微服务架构
特征 自动化部署,端点智能化,语言和数据的去中心化控制.
架构 一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。可通过全自动部署机制独立部署，共用一个最小型的集中式的管理。服务可用不同的语言开发，使用不同的数据存储技术。
去中心化基础设施
去中心化数据库
微服务设计模式
聚合式(推荐)
代理(推荐)
链式
分支
异步消息
微服务实现
通信方式 REST和RPC RPC框架
- Dubbo/ Dubbox
阿里巴巴公司开源的一个Java高性能优秀的服务框架，可以和Spring框架无缝集成，相关资料很丰富。 遗憾的是已经停止维护了，相关的依赖类比如Spring，Netty还是很老的版本。倒是当当网之类的再继续维维护，即Dubbox，并且实现了REST的支持。 Dubbo主要实现了服务治理，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现。 所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难，不能让各环节人员真正的专注于业务逻辑。
Motan 新浪微博的服务治理框架，2016年5月开源，Motan是一个小而精的 RPC 框架，它的特点是简单、易用，是一个轻量级 RPC框架。 与Dubbo相比，Motan在功能方面并没有那么全面，也没有实现特别多的扩展。用的人比较少，功能和稳定性有待观望。对跨语言调用支持较差，主要支持java。
Sprint Cloud(推荐) Spring Cloud 完全基于Spring Boot，是一个非常新的项目，2016年才 1.0 release。版本提升非常迅速，发展势头良好。 Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些。服务调用方式是基于REST API的。 缺点是项目很年轻，很少见到国内业界有人在生产上成套使用，一般都是只有其中一两个组件。相关的技术文档大部分是英文的，案例也相对较少，使用的话需要摸索的时间会长一些。
gRPC Google发布的开源RPC框架，高性能、开源、将移动和HTTP/2放在首位的通用的RPC框架，基于HTTP/2, netty4.1, proto3, 拥有非常丰富而实用的特性，堪称RPC 框架的典范。 但它本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发
Spring Cloud和Dubbo的对比
Spring Cloud和Dubbo都是微服务开发框架。不是新的技术就一定是好的技术。Dubbo优势在于开发简单，效率高。Spring Cloud优势在于功能全面且可靠性高。
Spring Cloud版本号说明
常见版本号说明
开发中，使用的框架版本，最好是RELEASE版本或Final版本。 常见版本号格式为： x.y.z.stage
- x - 数字格式主版本号，当功能模块有较大更新或者整体架构发生变化时，主版本号会更新。
- y - 数字格式次版本号，次版本表示只是局部的一些变动。
- z - 数字格式修正版本号，一般是bug的修复或者是小的变动。
- stage - 希腊字母版本号，也称为阶段版本号。用于标注当前版本的软件处于哪个开发阶段。常用的阶段版本包括：BASE、ALPHA、BATE、RELEASE/FINAL。
- BASE - 设计阶段。只有相应的设计没有具体的功能实现。
- ALPHA - 软件的初级版本。存在较多的bug。
- BATE - 表示相对ALPHA有了很大的进步，消除了严重的bug，还存在一些潜在的bug。
- RELEASE/FINAL - 该版本表示最终版，即正式发布版本。
2. Spring Cloud版本号说明 Spring Cloud是一个包含若干子框架的框架集合体，是一个完整的微服务框架体系，如果使用场景版本号来进行标记，容易混淆主框架版本和子框架版本标记。所以Spring Cloud使用一种全新的版本号来对主框架进行版本标记，而子框架的版本标记大多还是使用常用版本号标记的。 Spring Cloud版本格式如： 版本号命名.stage 版本号命名：Spring Cloud主框架版本号是使用英国伦敦地铁站名称来进行标记的，并根据地铁站名称的首字母的英文自然升序排列来识别版本的递增。如：Angle、Brixton、Camden、Dalston、Edgware、Finchley等。后续版本提升会继续根据首字母升序排列。
- stage：阶段版本号。常用的阶段版本包括：BUILD-XXX[SNAPSHOT]、GA、PRE(M1、M2等)、RC、SR。
- BUILD-XXX[SNAPSHOT] - 开发版本、一般是开发团队内部使用。
- GA - 稳定版，内部开发到一定阶段了，各个模块集成后，经过全面测试发现没有问题，可对外发行了。这个时候叫GA(General Availability)。基本上可以使用了。没有严重的BUG问题，但是有未测出的BUG隐患。不推荐商业使用。
- PRE - 里程碑版，由于GA还不属于公开发行版，里面还有些功能不完善或者bug，于是就有了milestone（里程碑版）。milestone版主要修复了一些bug。一个GA后，一般会有多个里程本版。例如 M1 M2 M3......。不推荐商业使用。
- RC - 候选发布版，从BUILD后到GA在到M基本上系统就算定型了，这个时候系统就进入Release Candidate（候选发布版）。该阶段的软件类似于最终发行前的一个观察期，该期间只对一些发现的等级高的bug进行修复。发布RC1 RC2等版本。可以考虑RC版本。
- SR - 正式发布版，公开正式发布。正式发布版一般也有多个发布，例如 SR1 SR2 SR3等等，一般是用来修复大bug或者优化。最好使用SR版本。
