点击下方图片可了解Kubernetes培训详情。
本篇文章是整理笔者在学习微服务时的入门篇,将探讨以下几点:
什么是单体架构及其优劣
什么是微服务
什么是微服务架构及其优劣
微服务和微服务架构的区别
单体架构与微服务架构的区别
微服务的适用场景
微服务架构所涉及的开发框架有哪些
如何选择框架的不同版本
单体架构
什么是单体架构
简单来说就是一个war包打天下,war包中就包含了各种功能和资源,比如JSP、JS、CSS,业务就是各个功能模块,如下图:
单体架构优缺点
优点:
架构简单,少了很多微服务中的问题(下文会讲是哪些问题)
开发、测试、部署简单,特别是部署
缺点:
随业务扩展,代码量越来越多,由于开发人员水平不同,代码质量参差不齐,改动代码时牵一发而动全身,开发人员如履薄冰
部署慢,由于代码量过多,每次部署可能需要几分钟甚至几十分钟
扩展成本高,根据单体架构图,假若支付模块为CPU密集型,需要大量计算,即需要更好的CPU,若订单模块为IO密集型,需要大量磁盘读写,即需要更好的内存和磁盘。单体架构又不支持单模块扩展,则我们就需要更好的CPU、内存、磁盘,那么硬件成本就会飞速上涨
不利于新技术发展,想想老板突然一天说我们把Struts2项目往Spring Boot上迁移……
微服务与微服务架构
什么是微服务
微服务的核心就是将传统的单体架构拆分成单个服务,将业务间进行解耦,每个服务可以单独部署。可以拥有自己的数据库这样拆分出来的服务就叫做微服务。
就比如说,单体架构中有订单、支付、物流、积分等业务,拆分成微服务有订单服务、支付服务、物流服务、积分服务。
这样拆分出来有什么意义呢?
单体架构中若非核心模块出现重大Bug,比如积分模块内存溢出,就会导致整个项目宕机。
但若是拆分成微服务,则只是说积分服务不能使用,但核心服务并不会受到影响。
什么是微服务架构
微服务架构是一种架构风格,包含如下几个特点:
将一个单一应用程序开发为一组小型服务
每个服务运行在自己的进程中
服务之间通过轻量级的通信机制(http rest api)
每个服务都能够独立的部署
每个服务甚至可以拥有自己的数据库
微服务与微服务架构的区别
微服务是服务的大小和对外提供的单一功能,微服务架构是指把一个个微服务管理起来,对外提供的一套完整服务。
微服务架构的优缺点
优点:
每个服务足够小,内聚高,代码更易理解,相较于单体架构,修改几行代码可能需要对整个系统逻辑都要理解
易开发,单个服务功能集中
单个服务可以由小团队进行开发,效率高
扩展成本低,按需扩缩容
前后端分离,Java开发人员能更集中精力关心后端接口的安全性和效率
每个服务拥有独立的数据库,也可以多个服务使用一个数据库
缺点:
增加运维人员工作量,可能会部署非常多的war包(Kubernetes + Docker + Jenkins)
服务之间相互调用,增加通信成本
数据一致性问题(分布式事务问题),性能监控等
问题定位时间成本增加
单体架构和微服务架构的区别
单体架构扩展
并发增加,上集群,硬件成本高。
微服务架构扩展
并发增加,灵活扩展,降低硬件成本,但运维成本、开发成本上升。
数据存储区别
单体架构:仅有一个数据库
微服务架构:每个微服务都可以有一个数据库
微服务的适用场景
适用于:
大型复杂项目(上百万行代码的项目T_T)
快速迭代项目(一天一更,吐血QAQ)
高并发项目(考虑弹性扩缩容T~T)
不适用:
业务稳定,就修修BUG,改改数据
迭代周期长,发布频率按月来算的
开发微服务的框架
相关框架
Spring Boot,快速开发微服务的Web框架
Spring Cloud,微服务架构的一套工具集
Spirng Cloud Alibaba,阿里提供的符合Spring Cloud标准的,一套微服务架构工具集
下图便是Spirng Cloud Alibaba提供的一套工具集,注意虽然有些备注是开源,但只是部分开源,一些核心功能依旧需要付费才能使用,比如Sentinel,开源的话本地限流配置是不能持久化的(可以选择付费,大佬可以改源代码来解决该问题)
如何选择框架的版本
Spring Boot
以2.1.6 RELEASE版本为例:
其中2:表示的主版本号,表示是我们的Spring Boot第二代产品
其中1:表示的是次版本号,增加了一些新的功能但是主体的架构是没有变化的,是兼容的
其中6:表示的是bug修复版
所以2.1.6合起来就是Spring Boot的第二代版本的第一个小版本的第6次bug修复版本。
RELEASE:存在哪些取值呢?
snapshot(开发版本)
M1……M2(里程碑版本,在正式版发布之前会出几个里程碑的版本)
release(正式版本)
所以选择版本时请认准release。
Spring Cloud
第一代版本:Angle
第二代版本:Brixton
第三代版本:Camden
第四代版本:Edgware
第五代版本:Finchley
第六代版本:GreenWich
第七代版本:Hoxton(还在酝酿中,没正式版本)
这种发布的版本是以伦敦地铁站发行地铁的站
为什么我们的Spring Cloud会以这种方式来发布版本,因为假如我们传统的5.1.5 release这种发布的而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版本先等等
推荐SR2以后的可以放心使用
Spring Boot、Spring Cloud、Spring Cloud Alibaba
这三个框架的版本关系,及推荐使用的版本如下:
原文链接:https://segmentfault.com/a/1190000022619522
Kubernetes实战培训
Kubernetes实战培训将于2020年7月24日在深圳开课,3天时间带你系统掌握Kubernetes,学习效果不好可以继续学习。本次培训包括:云原生介绍、微服务;Docker基础、Docker工作原理、镜像、网络、存储、数据卷、安全;Kubernetes架构、核心组件、常用对象、网络、存储、认证、服务发现、调度和服务质量保证、日志、监控、告警、Helm、实践案例等,点击下方图片或者阅读原文链接查看详情。