一、微服务
1. 什么是微服务
官网：https://martinfowler.com/articles/microservices.html
起源于： 25 March(3月) 2014 作者：James Lewis & Martin Fowler
[摘自官网] In short, the microservice architectural style is an approach to developing a single application as a suite 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 deployable 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.
- - a suite of small services：一系列微小服务
- - running in its own process：运行在自己的进程里
- - built around business capabilities：围绕自己的业务开发
- - independently deployable：独立部署
- - bare minimum of centralized management of these services：基于分布式管理
官方定义：微服务就是由一系列围绕自己业务开发的微小服务构成，他们独立运行在自己的进程里，基于分布式管理。
通俗定义：微服务是一种架构，这种架构是将单个的整体应用程序分割成更小的项目相互关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过api来实现。这些独立的微服务不需要部署在同一台
虚拟机，同一个系统和同一个应用服务器中。
集群（cluster）：同一种软件服务的多个服务节点共同为系统服务过程，称之为软件服务集群。
分布式（distribute）：不同的软件集群共同为一个系统提供服务，这个系统称之为分布式系统。
2. 为什么微服务？
单体应用
# 优点：
- 单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。
# 缺点：
- 应用随着时间的推进，加入的功能越来越多，业务功能逐渐庞大，一个项目中很有可能数百万行的代码，互相之间繁琐的jar包。
- 久而久之，开发效率低，代码维护困难。
- 项目整体技术迭代，采用新的技术，新的框架或者语言，是不可能的。
- 任意模块的漏洞或者错误都会影响这个应用，降低系统的可靠性。
微服务架构应用
# 优点：
- 将每个服务拆分成单一职责的小服务，进行独立部署，服务之间统过网络进行通讯。
- 每个服务单独管理，高度自治，可自行选用开发技术。
- 各服务有自己单独的职责，服务之间松耦合，避免因一个模块的问题导致服务崩溃。
# 缺点：
- 开发人员要处理分布式系统的复杂性。
- 多服务运行难度，随着服务的增加，运维的压力也在增大。
- 服务治理 和 服务监控 是关键。
二、架构的演变
1. 架构的演变过程
[单一应用架构] --> [垂直应用架构] --> [分布式服务架构] --> [流动计算架构]||[微服务架构] --> [未知]
摘自dubbo官网：https://dubbo.apache.org/zh/docs/v2.7/user/preface/background/
# All in One 单一架构
- 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，
用于简化增删改查工作量的数据访问框架(ORM)是关键。
（JSP + MySQL + Tomcat）
# Vertical Application 垂直架构
- 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆
成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。
（struts struts2 spring springmvc springboot）
# Distribute Service 分布式服务架构
- 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形
成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合
的分布式服务框架(RPC)是关键。
（tomcat集群、MySQL集群、redis集群）
OSI七层：物理层 数据链路层 网络层 传输层(rpc) 会话层 表示层 应用层(http)
# Elastic Computiing 流动计算架构即微服务架构
- 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基
于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中
心(SOA)是关键。
^--^ 好的架构并不是设计出来的，一定是不断发展进化出来的！！！
2. 微服务架构解决方案
Dubbo阿里系
最早期 dubbo(spring、springboot(兼容问题)) + zookeeper
- 初出茅庐：2011年末，阿里巴巴在GitHub上开源了基于Java的分布式服务治理框架dubbo，之后它成为了国内该类开源项目的佼佼者，许多开发者对其表示青睐。同时先后由不少公司在实践中基于dubbo进行分布式系统架构，目前在GitHub上，它的fork、star数
均已破万。dubbo致力于提供高性能和透明化的rpc远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能rpc实现服务的输出、输入功能和spring框架无缝集成。dubbo包含远程通讯、集群容错、自动发现三个核心部分。
- 停止维护：从2012年10月23日dubbo 2.5.3发布后，在dubbo开源将满一周年之际，阿里基本停止了对dubbo的主要升级。只在之后的2013年和2014年更新过两次对dubbo2.4的维护版本，然后停止了所有维护工作。dubbo对spring的支持也停留在spirng2.5.6版
本。
- 死而复生：多年漫长的等待，随着微服务的火热兴起，在国内外开发者对阿里不升级维护dubbo的吐槽声中，阿里终于开始重新对dubbo的升级和维护工作。在2017年9月7日，阿里发布了dubbo的2.5.4版本，距离上一个版本2.5.3版本已经接近快5年时间了。在随
后的几个月中，阿里的dubbo团队以差不多每月一版本的速度开始快速升级迭代，修不了dubbo老版本多年来存在的许多bug，并对spring等组件的支持进行了全面升级。
- 2018年1月8日，dubbo的创始人之一梁飞在dubbo交流群里透露了dubbo 3.0版本正在动工的修奥西。dubbo3.0内核与dubbo2.0完全不同，但兼容dubbo2.0。dubbo3.0将以Streaming为内核，不再是dubbo时代的rpc，但是rpc会在dubbo3.0中变成远程streaming对
接的一种可选形态。从dubbo新版本的路线规划来看，新版本的dubbo在原有的服务治理的功能基础上，将全面拥抱微服务解决方案。
- 结论：当前由于rpc协议、注册中心数据不匹配等问题，在面临微服务基础框架选型时dubbo与springcloud只能二选一，这也是为什么大家总是拿dubbo和springcloud做对比的原因之一。dubbo之后回积极寻求适配到springcloud生态，比如作为spirngcloud的二进制
通信方案来发挥dubbo的性能优势，或者dubbo通过模块化以及对http的支持适配到springcloud。
springcloud技术栈
spring cloud netflix 最早(16-17年)
- 基于美国Netflix公司开源的组件进行封装，提供了微服务一站式的解决方案
spring cloud alibaba 阿里巴巴的解决方案
- 在spring cloud netflix的基础上封装了阿里巴巴的微服务解决方案
spring cloud spring 自己封装微服务解决方案
- 目前spring官方趋势正在吸收Netflix组件的精华，并在此基础上进行二次封装优化，打造spring专
有的解决方案。
三、SpringCloud
1. 定义
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 为开发者提供了快速构建分布式系统中一些常见模式的工具（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态）。分布式系统的协调导致了样板模式，使用 Spring
Cloud 开发人员可以快速建立实现这些模式的服务和应用程序。
# 通俗理解：
- spirngcloud是一个涵盖多个子项目的开发工具集，集合了众多开源框架，它利用了spinrgboot开发的便利性实现了很多功能，如服务注册、负载均衡等。springcloud在整合过程中主要是针对Netflix开源组件的封装，springcloud的出现真正的简化了分布式架构的开
发。
Netflix 是美国的一个在线视频网站，微服务界的翘楚，他是公认的大规模生产微服务的杰出实践者，Netflix的开源组件已经在他大规模分布式微服务环境中经过多年的生产实战验证，因此springcloud中很多组件都是基于Netflix。
2. 核心架构及其组件
# 核心组件说明
- eurekaserver、consul、nacos 服务注册组件
- rabbion & openfeign 负载均衡 和 服务调用组件
- hystrix & hystrix dashboard 服务熔断器 和 服务监控组件
- zuul、gateway 服务网管组件
- config 统一配置中心组件
- bus 消息总线组件
......
3. spirngcloud版本命名
spirngcloud是一个由众多子项目组成的大型综合项目，原则上每个子项目上有不同的发布节奏，都维护自己的发布版本号。为了更好的管理springcloud的版本，通过一个资源清单BOM(Bill Of Materials)，为避免与子版本号的发布号混淆，所以没有采用版本号的方
式，而是通过命名的方式。这些字母都是按照字母顺序排列的。如伦敦的地铁站的名称（“天使”是第一个版本，“布里斯顿”是第二个版本，“卡姆敦”是第三个版本）。当单个项目的点发布累计到一个临界量，或者其中一个项目中有一个关键缺陷需要每个人都可以使
用时，发布序列将推出名称以“.SRX”结尾的“服务发布”，其中“X”是一个数字。
# 伦敦地铁站名称
- Angel、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich、Hoxton
4. springcloud与spirngboot的版本对应关系
Spring Cloud Dalston, Edgware, Finchley, and Greenwich have all reached end of life status
and are no longer supported.
- Brixton 2017年Brixton and Angel release 官方宣布报废
- Camden 2018年Camden release 官方宣布报废
- Dalston 2018年12月官方宣布报废
- Edgware 将遵循springboot1.5.x的生命周期结束