浅谈什么是微服务?微服务与单体架构的区别

文章目录

      • 单体架构
        • 单体架构存在的问题
      • 什么是微服务
        • 微服务的优点
        • 微服务面临的挑战
        • 微服务设计原则
        • 技术选型(此处指提到Java)

单体架构

       在了解微服务之前,我们现在谈谈单体架构的项目,什么是单体架构呢,单体架构指的就是所有的程序都在一个项目中;就像当初我们在以SSM、SSH为项目架构的时期,项目是打成一个war包在服务器运行的。这个war包包含了应用的所有系统功能,这样的项目架被称为单体架构。

单体架构存在的问题

       我们来逐个分析一下。首先,单体架构的应用是比较容易部署和测试的,在项目初期,单应用可以很好的运行。但是随着项目的不断完善,以及开发人员的不断加入。代码量会急剧增加;单体应用也会变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。下面列举了一些单体应用存在的问题:

  • 复杂性高:笔者之前有幸修改过一次较老的代码,使用的是SSH架构的组件,里面代码量也极其庞大,在修改的时候小心翼翼,找代码的时候也是极其繁琐复杂,改个BUG生怕导致项目崩溃掉。
  • 技术债务:随着时间的迁移,需求变更和人员更迭,会逐渐形成技术债务,并且越积越多,“不坏不修”,这在平时诸位开发的时候神佑体会吧~~~嘻嘻嘻,这在单体应用中这种思想会更加凸出。
  • 部署频率低:随着代码增多,构建和部署的时间也会增加。而在单体应用中,每次功能的变更和缺陷的修复都会导致重新部署整个应用。全量部署的方式耗时长,影响范围大,风险较高。这使得应用上线部署的频率降低。因为部频率低又导致两次发布之间会有大量的功能变更和缺陷修复,出错概率比较高。
  • 可靠性差:某个应用BUG、例如:死循环、OOM等。可能会导致整个应用崩溃。
  • 可扩展能力受限:因为单体架构要进行扩展的话只能是作为一个整体进行扩展。无法根据业务模块的需求进行伸缩。
  • 阻碍技术创新:单体应用往往使用统一的技术平台或方案解决所有的问题,团队中的每个成员都必须使用相同的开发语言和框架,要引入新的框架和技术可能会比较困难。比如几万行的项目使用Struts2构建的,如果想要改用SpringMVC的话,需求成本是比较高的,同时风险也是比较高的。

什么是微服务

       简单来说,微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。从中我们可以看到微服务架构具备以下特性:

  • 每个微服务都可以独立运行在自己的进程里
  • 一系列独立运行的微服务共同构建起整个系统
  • 每个服务为独立的业务开发,一个微服务值关注某个特定的功能,例如订单管理、用户管理等。
  • 微服务之前通过一些轻量级的通信机制进行通信,例如通过Restful API进行吊桶
  • 可使用不同的语言与数据存储技术。
  • 全自动的部署机制

微服务的优点

微服务架构有以下优点:

  • 易于开发和维护
  • 单个微服务启动较快
  • 局部修改容易部署
  • 技术栈不受限
  • 耦合性低
  • 按需伸缩

微服务面临的挑战

  • 运维成本较高:更多的服务意味着更多的运维投入,单体架构只需要保证一个应用的正常运转,而微服务要保证成百上千个服务的正常运行
  • 分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
  • 接口调整成本较高:微服务之间是通过接口进行通信的。如果某一个微服务被几百个服务组件调用的话,一旦这个接口入参等被修改,这几百个服务调用的接口都要进行调整。

微服务设计原则

  • 单一职责原则:指的是一个单元(类、方法或者服务等)只关注整个系统这功能中单独、有界限的一部分。单一职责原则可以帮助我们更加优雅开发、更敏捷地交付。
  • 服务自治原则:服务自治是指每个微服务应具备独立的业务能力、依赖和运行环境。在微服务架构红,服务是独立的业务单元,应该读其他服务高度解耦。每个微服务从开发、测试、构建、部署、都应当可以独立运行,而不应该依赖于其他服务。
  • 轻量级通信机制:微服务之间应该通过轻量级的通信机制进行交互。常用的协议有REST、AMQP等
  • 微服务粒度:微服务划分的粒度是个难点,也是常常讨论的焦点。应当使用和,里的粒度划分微服务,而不是一味地吧服务做小。代码量的多少不能作为微服务划分的依据,因为不同的微服务本身的业务复杂性不同,代码量也不同。

技术选型(此处指提到Java)

相对于单体应用的交付,微服务应用的交付要复杂的多。不仅要开发框架的支持,还需要一些自动化的部署工具支持,以及Iaas、Paas、Caas的支持。

功能 方案
服务注册中心 Zookeeper、Nacos、Eureka
服务配置中心 Nacos、Springcloud Config、Apollo、Zookeeper
服务网关 Zuul、Springcloud Gateway
服务调用 RestTemplate、Ribbon、Feign(OpenFeign)
负载均衡 Ribbon、OpenFeign
断路器 Hystrix、Sentinel
分布式消息 Springcloud Stream + kafka、RabbitMQ、RocketMQ
分布式事务 Seata 、Redission、TX-ICN

你可能感兴趣的:(微服务,分布式,java,编程语言,设计模式,大数据)