微服务架构

什么是微服务

一种可以采用不同开发语言开发,将单体应用开发为一组小型服务,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制,可以通过全自动部署机制独立部署。

微服务架构图

微服务架构图
微服务架构图

微服务架构的特征

  • 每个微服务可独立运行在自己的进程里
  • 一系列独立运行的微服务共同构建起整个系统
  • 服务独立,一个微服务只关注某个特定的功能
  • 轻量级通信机制
  • 可以使用不同的开发语言开发
  • 全自动部署机制

微服务架构的优点

  • 易于开发和维护 单个服务只会关注一个特定的业务功能,所以它业务清晰、代码量较少。
  • 单个微服务启动较快
  • 易于局部修改和部署
  • 技术栈不受限 可以结合项目业务及团队的特点,合理地选择技术栈。
  • 细粒度的伸缩和扩展

微服务架构面临的挑战

  • 运维要求较高 更多的服务意味着更多的运维投入。 在微服务中,需要保证几十甚至几百个服务的正常运行与协作,这个运维带来了很大的挑战。
  • 分布式固有的复杂性 微服务构建的是分布式系统。 对于分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
  • 接口调整成本高 如果修改某一个服务的API,使用了所有该接口的服务都需要做调整。
  • 重复劳动 很多服务可能都会用到相同的功能,而这个功能并没有达到分解为一个服务的程度,这个时候,可能多个服务都会开发这一个功能,从而导致代码重复。 在多语言环境下更是如此。

微服务技术选型考虑因素

  • 文档丰富程度
  • 社区活跃度
  • 技术栈生态
  • 开发效率
  • 运行效率
  • 成功案例

单体应用架构的优点

  • 易于开发
  • 易于部署
  • 易于测试

单体应用架构面临的挑战

  • 复杂性高 模块多、模块边界模糊、依赖关系不清晰、代码质量参差不齐 ......
  • 技术债务 随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务,并且越积越多。 “不坏不休”这在软件开发中非常常见,在单体应用中这种思想更甚。
  • 运维风险 系统升级、Bug修复、故障排查都存在很大的风险。
  • 部署频率低 全量部署方式时间长、影响范围大、风险高,这使得单体应用项目上线部署的频率较低。
  • 系统性风险 某个bug可能导致整个应用崩溃。
  • 扩展能力受限 单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。
  • 阻碍技术创新 单体应用往往使用统一的技术平台或方案解决所有的问题,团队中的每个成员都必须使用相同的开发语言和框架,要想引入新框架或新技术平台会非常困难。
坚持原创技术分享,您的支持将鼓励我继续创作!
0%