微服务架构整理-(一、微服务架构的发展)

微服务架构的发展

  • 单体应用架构
    • 优点
    • 缺点
  • 垂直应用架构
    • 优点
    • 缺点
  • 分布式架构
    • 优点
    • 缺点
  • 面向服务的架构(SOA)
    • 优点
    • 缺点
  • 微服务架构
    • 优点
    • 缺点
  • SOA与微服务之间的关系

工作中常用到微服务架构,知识点零零散散,这里稍微整理一下。
微服务架构的诞生是建立在各代程序员的努力之下,先后经历了单体应用架构、垂直应用架构以及分布式应用架构,并非一朝一夕。

单体应用架构

此架构是将所有的功能集成于一个服务中,即最终会打包成一个具体的应用,例如jar,war。每个项目包括每一层每一块里编写所有的代码。例如一个web工程里面包括了前端页面,web层代码,Service层代码,DAO层代码,把这些代码打包到一个项目当中,放到web容器中启动。如图所示:

微服务架构整理-(一、微服务架构的发展)_第1张图片

优点

开发简单,适用于小型应用

缺点

显然,这种架构易于开发、维护和部署。在用户量不多的情况下,该架构完全可以满足需求,但一旦用户量以及业务的复杂化,再加上代码的高度耦合,系统的维护和横向扩展异常困难。当用户量达到需要负载均衡来支持时,不得不使用多台服务器,但并不是应用中的每个功能模块都需要负载均衡,因此在扩展时必然会导致资源的浪费。例如:订单管理模块每秒访问1k次,用户管理每秒200次,这时扩展时连带用户管理一起扩展了,意义不大。总而言之,单体不易扩展与维护,代码的耦合度高。

垂直应用架构

由于单体应用架构的种种问题,先辈们开始考虑将各功能模块抽取成独立的子工程,每个子工程跑在一个容器中。例如:
微服务架构整理-(一、微服务架构的发展)_第2张图片

如果用户中心访问较多,只需要针对用户中心进行扩展就可以了。

优点

解决了高并发问题
可针对不同的模块进行优化
方便水平扩展
容错性高(其中一个系统出现了问题了,不影响其他系统,只需要针对出错的系统进行停机维护即可)

缺点

系统之间相互独立:需要为相互作用系统建立联系
大量的重复工作

分布式架构

把一个垂直应用进行业务上的抽取,抽取成两部分内容。一个是基础服务,另一个是业务功能,通过业务功能去调用相应的基础服务就构成了分布式应用。这样就很好的解决了服务与服务之间的调用。例如:
微服务架构整理-(一、微服务架构的发展)_第3张图片

优点

解决了服务与服务之间调用的问题,即减少了服务与服务之间的耦合度

缺点

随着服务层体积的增大,应用越来越多,服务的评估,治理与统一治理越来越难

面向服务的架构(SOA)

针对分布式架构缺点,形成了SOA(Service-Oriented Architecture)概念,即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
站在功能的角度,把业务逻辑抽象成可利用、可组装的服务,通过服务的编排实现业务的快速再生,目的:把原先固有的业务功能转变为通用的业务服务,实现业务逻辑的快速利用。比较流行的SOA有ESB,DUBBO。
微服务架构整理-(一、微服务架构的发展)_第4张图片

优点

抽取公共的功能为服务,提高开发效率
对不同的服务进行集群化部署解决系统压力
基于ESB/DUBBO进一步减少了系统的耦合

缺点

抽取服务的粒度较大
虽然基于ESB/DUBBO进一步减少了系统的耦合,但是耦合还是存在的,且不低

微服务架构

针对SOA的缺点,新的一种架构诞生了,即微服役架构。通过对服务尽可能的拆分,直到不能拆分为上并独立打包运行,服务调用层与服务提供方通过轻量级的http协议进行交互,达到完全解耦的效果,每次交互只需要一个简单的http请求即可,无需复杂的调用技术。每个服务遵循单一职责原则,通过http接口向外提供功能。
微服务架构整理-(一、微服务架构的发展)_第5张图片

优点

通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队的交付周期将缩短,运维成本也奖大幅度下降
微服务遵循单一职责原则,采用restful等轻量级协议传输

缺点

微服务过多,服务治理成本高,不利于系统维护
分布式系统开发的技术成本高(容错、分布式事物等)

SOA与微服务之间的关系

SOA它是一种设计方法,其中包含多个服务,服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。
微服务架构 和SOA类似,它是在SOA基础上的升华,强调的重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分成多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

功能 SOA 微服务
组件大小 大块业务逻辑 单独任务或小块业务逻辑
耦合度 通常松耦合 总是松耦合
公司架构 任何类型 小型、专注于功能交叉团队
管理 着重中央管理 着重分散管理
目标 确保应用能够交互操作 执行新功能、快速拓展开发团队
调用方式 RPC(较重) HTTP(较轻)

总之,微服务的发展不是一朝一夕,也是经过多年的迭代,最终成为广受欢迎的架构。

你可能感兴趣的