0%

微服务

微服务

为什么要提出微服务?

原本的单体架构应用是将一整个应用放在webapp下

  • 将整个应用打成war包,对于开发语言上是有限制的,整个应用只能使用java系列的语言,而微服务技术栈不受限,不同的服务可以使用不同的技术栈
  • 修改某一个小模块就需要部署整个应用,尤其是特别大的项目,部署一次很麻烦且费时,而微服务架构中每个服务都是一个独立的业务单元,服务与服务之间是独立的

什么是微服务?

马丁提出微服务架构的概念时列出来了一些对于微服务的描述

微服务是一种架构模式

  • 将单一应用分成一组小服务,根据业务模块划分服务
  • 每个服务可独立部署且相互隔离
  • 通过轻量级API调用(如HTTP调用)
  • 服务需保证良好的高可用性

既然要拆分,到底如何拆分服务呢,首先要遵守两个基本前提

  • 业务独立性 保证每个微服务是具有业务独立性的单元
  • 团队自主性 每个团队成员不超过十个人

微服务的优点

  • 易于开发和维护
  • 启动较快
  • 局部修改容易部署
  • 复杂的系统可以使用不同的语言进行开发,语言无关、平台无关,可以选择更适合的语言、工具或者平台来开发服务本身
  • 可以按需伸缩

微服务的缺点

  • 微服务会导致服务增多,且技术复杂
  • 对于运维要求相对提高
  • 查找问题变得更加复杂
  • 存在分布式的各种问题,如数据一致性问题
  • 多个应用存在依赖性,接口调整成本高,修改一个微服务的API可能所有涉及到的微服务都要修改
  • 重复代码,很多服务可能会使用相同的功能,可能需要各个服务都要开发这一功能

对于微服务之间的进程间调用,能访问一次就不要访问多次,尽量的粗粒度的返回更多的东西;而对于进程间的调用,是细粒度的

与SOA的区别

  • SOA是企业级的,自顶向下开展实施;微服务是团队级的,自底向上开展实施
  • SOA服务是由多个子系统组成,粒度大;微服务一个系统拆分为多个服务,粒度小
  • SOA服务之间使用企业服务总线来进行交互的集中式的服务架构;微服务是无集中式总线,松散的服务架构
  • SOA是单体架构系统,相互依赖,部署复杂;微服务可以独立部署

是否使用微服务

  • 看业务规模,单体应用太大不好维护时

欢迎关注我的其它发布渠道