一、前言:
本博客中所有的概念,小编都尽可能转换成了自己的理解,精简了概念!尽可能精简的来表达!
二、正文
1、什么是微服务架构?
一种系统架构上的设计风格!主旨:将一个系统拆分成可通信的多个独立部署运行升级扩展的微服务!
2、微服务与单体系统?
1)微服务与单体系统的区别、优点
单体初期方便开发和使用,但随系统逐渐增大,耦合性太强,维护成本大,难以控制,一挂全挂微服务独立,不会互相影响,容错性强,易维护,敏捷开发,自动化部署!
2)将单体系统变为微服务
——————本质:将代码依赖变成了服务间的通信依赖
a. 实施微服务的问题:i. 运维新挑战:进程数大大增加
ii. 接口一致性:拆分服务但业务依赖不会消除,服务间需要进行调用,所以需要更完善的接口和版本管理
iii. 分布式复杂性:服务独立部署并运行,只能通过通信来协作,分布式的问题都将存在,比如:网络延迟,分布式事物,异步消息等。
3)微服务架构九大特性、
a. 服务组件化:服务独立可独立更换升级b. 按业务组织团队:每个微服务都是针对特定业务的全栈实现,也就是说每个服务都要有一套完整的小团队,从而达到能全栈实现的目的
c. 做“产品”的态度:每个团队要对每个可独立部署运行的微服务的整个生命周期负责,所以都应该有做产品的态度
d. 智能端点与哑管道:不太理解(在单体应用中,主要通过函数调用交互协作,而在微服务中,因为服务不在一个进程,所以服务间通信会有不同,可以查下微服务架构中服务调用方式)
e. 去中心化治理:在实施微服务架构时,各个服务可以针对不同的业务特点选择不同的技术平台
f. 去中心化管理数据:可以将数据拆分到新的同平台的数据库实例中,也可以存储到不同平台的数据库实例中
g. 基础设置自动化:在实施微服务架构时,数据库,应用程序个头虽然小了,但数量也成倍增长。这会造成运维关注的内容,操作性任务成本增长,如果不妥然解决,必将成为运维人员的噩梦,所以基础设置自动化就是解决这个问题的。。解决办法:从一开始就构建“持续交付平台”如何构建持续交付平台:自动化测试和自动化部署缺一不可
h. 容错设计:微服务架构中,每个服务运行在独立进程,所以存在部分服务挂,其他正常运行的情况,而不存在一挂全挂的情况。为了更快速检测出故障并恢复服务,我们希望在每个服务中实现监控和日志记录。
演进式设计:初期以单体系统方式来设计实施, 随着系统发展,业务需要,架构师会将一些内容进行微服务处理,逐渐将单体系统中多变模块查分出来,而稳定不太变化的模块就形成一个核心微服务。