关于微服务入门篇

一. 引言

本篇文章是整理笔者在学习微服务时的入门篇，将探讨如下几点：

1. 什么是单体架构及其优劣
2. 什么是微服务
3. 什么是微服务架构及其优劣
4. 微服务和微服务架构的区别
5. 单体架构与微服务架构的区别
6. 微服务的适用场景
7. 微服务架构所涉及的开发框架有哪些
8. 如何选择框架的不一样版本

二. 单体架构

2.1什么是单体架构

简单来讲就是一个war包打天下，war包中就包含了各类功能和资源，好比JSP. JS. CSS，业务就是各个功能模块，以下图：

2.2单体架构优缺点

优势：

1. 架构简单，少了不少微服务中的问题(下文会讲是哪些问题)
2. 开发. 测试. 部署简单，特别是部署

缺点：

1. 随业务扩展，代码量愈来愈多，因为开发人员水平不一样，代码质量良莠不齐，改动代码时牵一发而动全身，开发人员如履薄冰
2. 部署慢，因为代码量过多，每次部署可能须要几分钟甚至几十分钟
3. 扩展成本高，根据单体架构图，倘若支付模块为CPU密集型，须要大量计算，即须要更好的CPU，若订单模块为IO密集型，须要大量磁盘读写，即须要更好的内存和磁盘。单体架构又不支持单模块扩展，则咱们就须要更好的CPU. 内存. 磁盘，那么硬件成本就会飞速上涨
4. 不利于新技术发展，想一想老板忽然一天说咱们把Struts2项目往Spring Boot上迁移...

三. 微服务与微服务架构

3.1 什么是微服务

微服务的核心就是将传统的单体架构拆分红单个服务，将业务间进行解耦，每一个服务能够单独部署. 能够拥有本身的数据库这样拆分出来的服务就叫作微服务。

就好比说，单体架构中有订单. 支付. 物流. 积分等业务，拆分红微服务，订单服务，支付服务，物流服务，积分服务

这样拆分出来有什么意义呢？

单体架构中若非核心模块出现重大Bug，好比积分模块内存溢出，就会致使整个项目宕机
但如果拆分红微服务，则只是说积分服务不能使用，但核心服务并不会受到影响

3.2什么是微服务架构

微服务架构是一种架构风格，包含以下几个特色：

1. 将一个单一应用程序开发为一组小型服务
2. 每一个服务运行在本身的进程中
3. 服务之间经过轻量级的通讯机制(http rest api)
4. 每一个服务都可以独立的部署
5. 每一个服务甚至能够拥有本身的数据库

3.3微服务与微服务架构的区别

微服务是服务的大小和对外提供的单一功能，微服务架构是指把一个个微服务管理起来，对外提供的一套完整服务

3.4微服务架构的优缺点

优势：

1. 每一个服务足够小，内聚高，代码更易理解，相较于单体架构，修改几行代码可能须要对整个系统逻辑都要理解
2. 易开发，单个服务功能集中
3. 单个服务能够由小团队进行开发，效率高
4. 扩展成本低，按需扩缩容
5. 先后端分离，Java开发人员能更集中精力关心后端接口的安全性和效率
6. 每一个服务拥有独立的数据库，也能够多个服务使用一个数据库

缺点：

1. 增长运维人员工做量，可能会部署很是多的war包(k8s + Docker + Jenkis)
2. 服务之间相互调用，增长通讯成本
3. 数据一致性问题(分布式事务问题). 性能监控等
4. 问题定位时间成本增长

3.5单体架构和微服务架构的区别

单体架构扩展

并发增长，上集群，硬件成本高

微服务架构扩展

并发增长，灵活扩展，下降硬件成本，但运维成本. 开发成本上升

数据存储区别

单体架构：仅有一个数据库
微服务架构：每一个微服务均可以有一个数据库

3.6微服务的适用场景

适用于：

1. 大型复杂项目(上百万行代码的项目T_T)
2. 快速迭代项目(一天一更，吐血QAQ)
3. 高并发项目(考虑弹性扩缩容T~T)

不适用：

1. 业务稳定，就修修BUG，改改数据
2. 迭代周期长，发布频率按月来算的

四. 开发微服务的框架

4.1相关框架

• Spring Boot 快速开发微服务的Web框架
• Spring Cloud 微服务架构的一套工具集
• Spirng Cloud Alibaba 阿里提供的符合Spring Cloud标准的，一套微服务架构工具集

下图即是Spirng Cloud Alibaba提供的一套工具集，注意虽然有些备注是开源，但只是部分开源，一些核心功能依旧须要付费才能使用，好比Sentinel，开源的话本地限流配置是不能持久化的(能够选择付费，大佬能够改源代码来解决该问题)

4.2如何选择框架的版本

Spring Boot

以2.1.6.RELEASE版本为例

• 其中2：表示的主版本号，表示是咱们的SpringBoot第二代产品
• 其中1:表示的是次版本号，增长了一些新的功能可是主体的架构是没有变化的，是兼容的
• 其中6:表示的是bug修复版

因此2.1.6合起来就是springboot的第二代版本的第一个小版本的 第6次bug修复版本

RELEASE:存在哪些取值呢？

1. snapshot(开发版本)
2. M1...M2(里程碑版本,在正式版发布以前会出几个里程碑的版本)
3. release(正式版本)

因此选择版本时请认准release

Spring Cloud

• 第一代版本:Angle
• 第二代版本:Brixton
• 第三代版本:Camden
• 第四代版本:Edgware
• 第五代版本:Finchley
• 第六代版本:GreenWich
• 第七代版本:Hoxton(还在酝酿中，没正式版本)
• 这种发布的版本是 以伦敦地铁站发行地铁的站

为何咱们的SpringCloud会以这种方式来发布版本，由于假如咱们传统的5.1.5release这种发布的而SpringCloud会包含不少子项目的版本就会给人形成混淆

• 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

总结：

1. 打死不用 非稳定版本/ end-of-life（不维护）版本
2. release版本先等等
3. 推荐SR2之后的能够放心使用

Spring Boot. Spring Cloud. Spring Cloud Alibaba

这三个框架的版本关系，及推荐使用的版本以下：

五. 参考

• Spring
• 微服务

六. 最后

如有不足，敬请指正虚心若愚，求知若渴