为什么要使用微服务架构?

一、传统的单体架构

1、什么是单体架构?

单体架构(Monolithic Architecture)是一种传统的软件架构模式,将整个应用程序作为一个单一的、统一的单元进行开发、部署和扩展。在单体架构中,所有的功能模块都被打包在一起,共享同一个代码库和数据库。

 

2、单体架构的缺点

  • 复杂性高

一个大型的项目可能包含的模块功能非常多,而模块之间的边界比较模糊,依赖关系不是很清晰,代码质量参差不齐,修改一个bug容易造成另一个隐藏的bug。

  • 可扩展性差

只能整体扩展,不能按业务模块的特点进行扩展。比如:当我们发现某一个功能模块的请求压力非常大时,想单独对这个功能做服务节点的扩展,对于单体架构来说是做不到的,只能整个系统做负载均衡。

  • 维护困难

随着应用程序的功能模块越来越多,代码库也会变得越发庞大和复杂,会导致新人学习周期拉长。

  • 技术栈受限制

整个系统只能使用单一的技术栈,无法针对业务模块的特点使用不同的技术栈。

  • 可靠性差

一个功能点的bug可能会导致整个应用程序的崩溃。

二、微服务架构

1、什么是微服务?

微服务架构是将整个大型复杂的应用程序拆分成若干个微小的服务,将系统各功能模块分配到各个微服务中,从而降低系统的耦合度,服务之间的通讯通常采用RPC协议或http协议。

 

2、微服务架构的优点

  • 易于开发和维护

每一个微服务都是独立部署的“小系统”,开发人员只需要关注这个服务自己功能模块的代码,所以代码量和功能相对小很多,开发理解相对也会简单一些,团队成员接手也会容易很多。

  • 服务启动速度快

单个微服务的代码量相对小很多,所以启动速度会快一些。

  • 按需伸缩

当我们发现某个服务的请求压力过大(较小)时,我们只需要对这个服务增加(减少)节点即可。

  • 稳定性更强

如果微服务应用崩溃了,一般情况下不会导致整个应用系统的宕机。

  • 技术栈不受限制

每个微服务可以选择合适的技术栈,不用局限于单一特定的技术体系。

3、微服务架构带来的问题

  • 部署节点变多,管理困难

随着拆分的服务数量越来越多,用传统的方式部署和管理配置会变得麻烦。

  • 分布式事务一致性问题

微服务之间的调用会存在数据一致性问题,需要引入分布式事务解决方案来处理。

  • 调用链路变长,问题追踪定位困难

一个微服务的数据如果依赖于其他服务,如果出现问题,如何定位找到问题的根源所在是相对比较困难的。

4、微服务框架

我们的项目要使用微服务架构模式的开发方式,那么就需要有一个微服务的框架来解决这些问题。推荐一个最接地气的.NET微服务框架Wing,项目地址:

gitee:https://gitee.com/linguicheng/Wing

github:https://github.com/linguicheng/Wing

热门相关:自古红楼出才子   千夫斩   梁医生又在偷偷套路我   来自地狱的男人   超级吸收