一、微服务架构概述

1、为什么会出现微服务

1.1、单体应用的问题

    单体应用——一个war包包含了所有功能的应用程序。

    问题:随着需求增加,一个单体项目会变得越来越臃肿,可维护性降低。

  • 复杂性高:模块多、依赖不清,混乱堆砌
  • 技术债务:技术人员变更,老代码难以维护修改
  • 部署频率低:每次简单修改就要整个臃肿项目重新部署,所以一般少部署
  • 可靠性差:一个小bug,可能导致整个项目的崩溃(如:死循环,OOM)

1.2、单体应用架构上的问题

    扩展能力受限——只能作为整体去扩展,无法灵活伸缩。如:有些模块计算密集,需要强劲CPU,有些IO密集需要大内存,揉在一个war包里部署,硬件上不好选择

    阻碍技术创新——引入新框架必须改整个项目,几乎不可能

由此,微服务就应运而生!

2、什么是微服务

2.1、简单定义

    (把之前的)单一应用开发成一组小型服务,服务间采用轻量级通信(如Http),这一组服务可以集中管理,每个服务可以用不同的语言技术来实现。

2.2、微服务的特性

  • 一个微服务运行在自己独立的进程中
  • 一个微服务实现某一特定功能(如订单管理)
  • 一个微服务可与同组其他服务用不同的语言技术

    如图:微服务特性模型

 

2.3、微服务的优点与挑战

2.3.1、优点

    一个微服务就是一个功能业务,业务清晰、代码少、启动快。技术上可以按需选用不同的语言、技术框架。如果某个微服务遇到瓶颈,可以按需增加配置

2.3.2、面临的挑战

  •     运维成本高——一组微服务要集中管理
  •     分布式固有复杂性——网络延迟、分布式事物、系统容错等
  •     接口调整成本高——微服务通信靠接口,用到该接口的地方都要修改
  •     重复劳动——不同微服务里可能出现同样的(不适合抽取,但)重复性的代码

2.4、微服务设计原则

  •     单一职责原则——只关注功能中单独、有界的一部分
  •     服务自制——独立业务能力、依赖和运行环境,高度解耦、独立运行
  •     轻量级通信机制——体量轻、跨语言、跨平台,如REST、AMQP
  •     微服务粒度——随业务场景定义

2.5、微服务架构的实现

2.5.1、技术选型

    框架——可选用spring cloud作为微服务开发框架,“开箱即用”提供了微服务的完整解决方案。(dubbo也可以但是主要针对Java项目)

    运行平台——不绑定运行平台,推荐使用Docker做部署

2.6、微服务架构图

微服务架构图

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试