什么是微服务? 微服务概念

什么是微服务?

GitHub demo 地址: https://github.com/TongBlackLittle/springCloud
该 demo 为 springCloud 全家桶的整合项目,抛开了业务逻辑,喜欢的给个星哈 可以留言交流一下

微服务的概念

“微服务” 源于 Martin Fowler 的一个博文,微服务是,系统架构的一种设计风格,将一个原本独立的服务拆分成,多个小型服务,
每个服务独立运行在在各自的进程中,服务之间通过 HTTP RESTful API 进行通信.每个小型的服务都围绕着系统中的某个耦合度,较高的业务进行构建.

和单体应用的区别

一个“单体项目”大致分为三个部分,‘数据源’,‘服务端处理’,‘客户端展示’,服务开发初期,业务逻辑都在一个应用中进行开发、测试、部署、,但是随着企业的发展,
业务模块的增多,移动端的发展,单体应用会变得越发臃肿.更改一个小功能,就需要部署整个项目维护成本变高.

为了解决单体应用臃肿难以维护, 产生了“微服务“, 将系统中的不同功能模块拆分成多个不同的服务,这些服务都能够独立部署和扩展 .由于每个服务都在自己的进程中,并且独立扩展
这样我们可以为每个服务,更加准确的评估性能容量评估,也可以更容易的发现系统瓶颈.

微服务的“缺点” 和实施

运维挑战

微服务中运维人员维护的进程数大量增加,需要运维人员对服务进行编排和组织,运维过程需要大量的自动化,需要运维人员有一定的开发能力.

接口一致性

服务拆分之后,业务逻辑依赖关系依然存在,所以当某个接口进行了修改,交互方也需要进行发布保证接口调用.需要更完善的接口管理,版本管理

分布式问题

由于微服务之间是通过通信进行协助,那么需要考虑的问题, 网络延时,分布式事务,异步消息都需要考虑

微服务优点

敏捷开发,自动化部署,服务解偶

微服务的九大特性

1.服务组件化

可以将服务比做,拼装电脑.cup、内存、显卡、硬盘,每个服务都可以独立更换升级,不影响其他单元.
每一个服务都可以独立开发,部署,有效避免一个服务,修改引起整个系统的重新部署.

2.按业务组织团队

决定如何划分微服务时,通常也意味着,团队进行重新规划和组织.以往的形式,DBA,运维,后端,前端,设计师.
微服务,则采用按照业务线的方式进行团队划分,可以减少服务内部修改,产生的消耗.团队边界也可以更清晰.

3.做“产品”的态度

在实施微服务时,应该以做产品的方式,对整合生命周期负责,而不是以项目的模式,以将成果交付给维护者,最终目标.

4.智能端点与哑管道

单体应用中,组件直接通过函数进行调用,而在微服务架构中,改成了RPC方式调用,服务之间通信繁琐
在微服务中会使用两种调用方式

• HTTP 的 RESTful API 轻量级的消息发送协议
• 轻量级的消息发送,类似于 RabbitMQ 等一些提供可靠的异步交换的中间件.

5.去中心化处理

单体应用通常会置顶统一标准,但是每种技术都有短板,可能因为底层原因,成为系统瓶颈.
实施微服务时,对服务本身的技术并不是那么敏感,每个服务可以根据自身的业务选用不同的技术平台.

6. 去中心化数据管理

实施微服务的时候,希望每个服务来管理自己的数据库,这就是“数据的去中心化”,根据不同的业务场景,可以使用不同的数据库,比如日志用 MaongoDB 用户登陆信息 Redis
由于使用不同的数据库实例,数据一致性成为了问题之一,分布式事务,本身难度很大,所以服务之间,要进行无事务调用,只要求在最后处理状态一致即可,过程中出现错误,通过补偿机制,来进行处理.

7.基础设施自动化

• 自动化测试:每次部署前需要进行自动化测试
• 自动化部署:解放枯燥重复操作以及多环境配置管理

8.容错设计

单体应用中,通常是一挂,服务全挂
微服务中通常是部署在独立进程中的,所以一个服务出现问题,不会影响其他服务.但是会出现,A->B->C C 服务崩溃等待,B 服务大量线程挂起,最终会影响 A 服务,这就是服务的"雪崩效应"
所以在设计微服务时,快速检测故障源,并尽可能的自动恢复是必须背设计和考虑的.

9.演进式设计

初期以单体应用方式进行设计和实施,随着业务的增长,将一些不经常变动的内从拆分成一个服务存放在架构之中.