原创

剖析微服务架构与单体应用架构

温馨提示:
本文最后更新于 2018年02月01日,已超过 2,444 天没有更新。若文章内的图片失效(无法正常加载),请留言反馈或直接联系我

微服务架构

什么是微服务

微服务架构风格是一种将单个应用程序开发为一套小型服务的方法,每个小型服务都在自己的流程中运行,并与轻量级机制(通常是HTTP资源API)进行通信。这些服务围绕业务功能构建, 可通过全自动部署机制独立部署。有一个集中管理的最低限度的这些服务,可以用不同的编程语言和使用不同的数据存储技术。

微服务架构图

微服务的优缺点

图片参考:微服务权衡

优点

  1. 易于开发和维护:一个微服务只会关注一个特定的业务功能,所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
  2. 单个微服务启动较快。
  3. 局部修改容易部署:单一应用只要有修改,就得重新部署整个应用。微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。
  4. 技术栈不受限制:在微服务架构中,可以结合项目业务及团队的特点,合理的选择技术栈。
  5. 按需伸缩:可根据需求,实现细粒度的扩展。

缺点

  1. 运维要求高:更多的服务意味着要投入更多的运维。
  2. 分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的问题。
  3. 接口调整成本高:微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有用到这个接口的微服务都需要进行调整。

微服务技术栈

微服务学习资源参考

总结微服务

  1. 微服务的核心就是将传统的单一应用,根据业务拆分成一个一个的服务,彻底地去耦合,每一个微服务提供单个业务功能的服务,一个服务做一件事。
  2. 在 IDEA 工具中使用Maven构建的一个个独立的Module,也就是使用SpringBoot开发的一个个小模块就是一个个微服务,将专业的事交给专业的模块来做。比如一个大型项目可能有上百个微服务,将这些微服务集中起来构成一个大的系统,对外暴露服务进行调用与使用。
  3. 从技术角度看就是一种小而独立的处理过程,类似进程概念,能够自行单独启动或销毁,拥有自己独立
    的数据库。

单体应用架构

什么是单体应用架构

一个应用中包含了应用程序的所有功能(比如:页面,代码,配置等),把应用打成一个war或jar包部署到Tomcat中,通常称为单体应用架构。

单体应用架构图

单体应用优缺点

优点

  1. 易于开发&测试:单个应用包含所有功能,不涉及多个应用的互联互调,便于在团队之间开发与测试。
  2. 易于部署:只需将单个应用打成war或jar包,进行部署到Tomcat即可,运维起来比较方便。
  3. 易于整体扩展:当应用负载压力大时,将这个应用复制几份,分别部署在不同的服务器上,再通过负载
    均衡即可提高应用的并发能力。

缺点

  1. 复杂性高:由于是单个应用,所以整个项目文件包含的模块非常多,导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐,混乱的堆在一起,使得整个项目非常复杂。以致每次修改代码,都非常小心,可能添加一个简单的功能,或者修改一个Bug都会带来隐藏的缺陷。
  2. 技术债务:随着时间的推移、需求的变更和技术人员的更替,会逐渐形成应用程序的技术债务,并且越积越多。
  3. 阻碍技术创新:对于单体应用来说,技术是在开发之前经过慎重评估后选定的,每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。
本文目录