微服务和微服务架构概念引入

一、单体架构

从单体架构说起 ，一个单体架构工程对应一个归档包(war)，这个war包包含了该工程的所有功能。我们成为这种应用为单体应用，也就是我们常说的单体架构(一个war包打天下)。 具体描述: 就是在我们的一个war包种，聚集了各种功能以及资源，比如JSP JS,CSS等。而业务种包含了我们的用户模块，订单模块，支付模块等等.

1.1 单体架构图

1.2 单体架构优缺点总结

优点:
①: 架构简单明了，没有”花里胡哨“的问题需要解决。
②:开发，测试，部署简单（尤其是运维人员 睡着都会笑醒）

缺点:
①：随着业务扩展，代码越来越复杂，代码质量参差不齐,会让你每次提交代码 ，修改每一个小bug都是心惊胆战的。
②:部署慢(由于单体架构，功能复杂) 能想像下一个来自200W+代码部署的速度 (15分钟)
③:扩展成本高，根据单体架构图 假设用户模块是一个CPU密集型的模块(涉及到大量 的运算)那么我们需要替换更加牛逼的CPU，而我们的订单模块是一个IO密集模块（涉 及大量的读写磁盘）,那我们需要替换更加牛逼的内存以及高效的磁盘。但是我们的单
体架构上 无法针对单个功能模块进行扩展，那么就需要替换更牛逼的CPU 更牛逼的内 存 更牛逼的磁盘 价格蹭蹭的往上涨。
④:阻碍了新技术的发展。。。。。。比如我们的web架构模块 从struts2迁移到 springboot，那么就会成为灾难性

二、微服务以及微服务架构

微服务的定义
①：英文:https://martinfowler.com/articles/microservices.html
②: 中文:http://blog.cuicc.com/blog/2015/07/22/microservices

2.1 微服务

微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程， 每个服务都能够单独部署，甚至可以拥有自己的数据库。这样的一个一个的小服务就是微服务架构.

①: 比如传统的单机电商应用, tulingshop 里面有 订单/支付/库存/物流/积分等模块(理 解为servcie)
②:我们根据 业务模型来拆分,可以拆分为 订单服务，支付服务，库存服务，物流服 务，积分服务 *
③*若不拆分的时候，我的非核心业务积分模块 出现了重大bug 导致系统内存溢出， 导致整个服务宕机. ,若拆分之后，只是说我的积分微服务不可用，我的整个系统核心功能还是能使用

2.2 微服务架构

微服务以及微服务架构的是二个完全不同的概念。
微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把 一个一个的 微服务组合管理起来，对外提供一套完整的服务。

微服务架构是一个架构风格, 提倡
①:将一个单一应用程序开发为一组小型服务.
②:每个服务运行在自己的进程中
③:服务之间通过轻量级的通信机制(http rest api)
④:每个服务都能够独立的部署
⑤:每个服务甚至可以拥有自己的数据库

微服务的优点
①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应 用，可能改几行代码 需要了解整个系统)
②: 开发简单，一个服务只干一个事情。（加入你做支付服务，你只要了解支付相关代 码就可以了）
③: 微服务能够被2-5个人的小团队开发，提高效率
④: 按需伸缩
⑤: 前后段分离, 作为java开发人员，我们只要关系后端接口的安全性以及性能，不要 去关注页面的人机交互(H5工程师)根据前后端接口协议，根据入参，返回json的回参
⑥:一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库.

微服务的缺点:
①:增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千 个war包 (k8s+docker+jenkis )
②: 服务之间相互调用，增加通信成本
③:数据一致性问题(分布式事物问题)
④:系能监控等,问题定位…

微服务的适用场景
①:大型复杂的项目…(来自单体架构200W行代码的恐惧)
②:快速迭代的项目…(来自一天一版的恐惧)
③:并发高的项目…(考虑弹性伸缩扩容的恐惧)

微服务的不适用场景
①：业务稳定，就是修修bug ，改改数据
②：迭代周期长 发版频率 一二个月一次.

三、Spring Cloud介绍

SpringCloud是程序员用来开发我们微服务的一整套技术解决方案.包含如下 服务注册发现，服务容错降级，服务网关，服务调用，服务调用负载均衡,消息等 Spring Cloud.

三、Spring Cloud Alibaba介绍

Spring cloud Alibaba是SpringCloud的一个子项目,是提供微服务开发的一站式 解决方案.包含微服务开发的必要组件。其基于SpringCloud 符合SpringCloud标准,是阿里的微服务的解决方案. 文档地址.

四、SpringCloud和SpringBoot的生产版本选择

4.1 SpringBoot版本说明

<parent>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring‐boot‐starter‐parent</artifactId>
	<version>2.1.6.RELEASE</version>
</parent>
其中2：表示的主版本号，表示是我们的SpringBoot第二代产品
其中1:表示的是次版本号，增加了一些新的功能但是主体的架构是没有变化的，是兼容的 
其中6:表示的是bug修复版
所以2.1.6合起来就是springboot的第二代版本的第一个小版本的第6次bug修复版本
①:snapshot(开发版本) 
②:M1...M2(里程碑版本,在正式版发布之前会出几个里程碑的版本) 
③:release(正式版本)

4.2 Spring cloud的版本说明

第一代版本:Angle
第二代版本:Brixton
第三代版本:Camden
第四代版本:Edgware
第五代版本:Finchley
第六代版本:GreenWich
第七代版本:Hoxton
这种发布的版本是 以伦敦地铁站发行地铁的站。
为什么我们的SpringCloud会以这种方式来发布版本,因为假如我们传统的 5.1.5release这种发布的而 SpringCloud会包含很多子项目的版本就会给人造成混 淆.

Spring cloud版本发布顺序是

SNAPSHOT：快照版本，随时可能修改

M： MileStone，M1表示第1个里程碑版本，一般同时标注PRE，表示预览版版。
RC 版本英文版名字叫Release Candidate（候选版本）一般标注PRE表示预览版

SR： Service Release，SR1表示第1个正式版本，一般同时标注GA：(GenerallyAvailable),表示 稳定版本。

还有一种RELEASE版本（正式版本） 比如 Greenwich版本顺序 Greenwich.release----->发现bug----->Greenwich.SR1------>发现bug----> Greenwich.SR2。

生产版本选择
打死不用 非稳定版本/ end-of-life（不维护）版本
release版本先等等(等别人去探雷) c:推荐 SR2以后的可以放心使用.