技术架构的演进之路:为什么需要微服务?

开发 架构
微服务是指开发一个单个小型的但有业务功能的服务,每个服务都有自己的处理和轻量通讯机制,可以部署在单个或多个服务器上。

[[414950]]

整体发展概览

服务架构一直处于演变之中,为了适合自己的业务,不断的去调整。

整体的发展历程如下:

技术架构的演进之路:为什么需要微服务?

开发者视角

从一个 java 开发者,感受大概经历了下面几个历程:

第一阶段:单体架构

早期,大部分IT系统都是单体系统,例如传统的SSH架构,此时前后端也没有分离,UI组件也包含在了控制层:

技术架构的演进之路:为什么需要微服务?

这个也就是老马刚毕业时候的架构,SSH 基本是面试必问。

不过现在这些都发生了一些变化,主流已经变成了 spring mvc + spring contaienr + mybatis。

只能说,spring,java 界永远的春天!

第二阶段:分布式架构

为了方便给系统扩容,以及增加系统的复用性,出现分布式系统。

另一方面,系统模块快速膨胀,为了降低系统内部的复杂度,于是对系统模块进行拆解,分不到不同的系统中,降低模块耦合,加快迭代速度。

ps: 其实主要是降低单个应用的复杂性,让每一个应用专注于一件事情。这样可维护成本大大降低,换言之,开发完后以后,可以让一个刚毕业的新人做运维。把开发者裁掉,降低成本。

主流主要是 SOA 和 MSA 两种体系。

SOA

早期的分布式系统是基于面向服务的架构SOA。

SOA是微服务的前身,主要是为了摆脱单体应用的问题,达到以下效果:

  1. 充分利用现有的基础设施;
  2. SOA体系结构依赖于消息传递(AMQP,MSMQ)和SOAP作为主要的远程访问协议。
  3. 快速响应业务变化;

架构图如下:

技术架构的演进之路:为什么需要微服务?

异构系统,也可以通过消息中间件的协议转换进行相互调用。

这个我倒是接触过一段时间,当时业务系统是 C# 开发,我所在的后端服务使用的是 java 技术开发。当时的协议使用的是 webservice。

但是用起来感觉不是很顺畅,主要缺点如下:

(1)WebService中常用的SOAP通信协议,通常使用XML格式进行通信,数据冗余,协议过重

(2)服务治理很不完善。

后来逐渐演变为了现在的 MSA(Micro-Service Archeticture 微服务架构),从而实现了更加松耦合以及更加灵活的系统。

MSA

微服务是一种软件开发技术——面向服务的体系结构(SOA)体系结构样式的变体,它将应用程序构造为松散耦合服务的集合。

在微服务体系结构中,服务是细粒度的,协议是轻量级的。

微服务架构图示

技术架构的演进之路:为什么需要微服务?

优点

微服务架构有很多重要的优点。

首先,它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变,但应用程序已被分解为可管理的模块或服务。

这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平,而这通过单体代码库很难实现。

因此,微服务开发的速度要快很多,更容易理解和维护。

第三,微服务架构可以使每个微服务独立部署。

最后,微服务架构使得每个服务都可独立扩展。

现在这种架构模式已经成为主流,个人感受最深的就是如果你只负责单一服务,你可以把他理解的比较透彻,而且维护起来也没有那么复杂。如果有功能变更,只上线对应的应用即可。

缺点

微服务的一些想法在实践上是好的,但当整体实现时也会呈现出其复杂性。

  • 运维开销及成本增加
  • 必须有坚实的 DevOps 开发运维一体化技能
  • 隐式接口及接口匹配问题
  • 代码重复
  • 分布式系统的复杂性
  • 异步机制
  • 可测性的挑战

个人感觉微服务最大的问题在于系统的拆分之后,很难有一个人可以知道系统的全貌,所以定位问题变得非常复杂。

举个例子,如果交易发生一笔失败,你可能要从API网关=》业务系统=》交易核心=》支付核心=》风控系统问一遍才能知道原因,最后发现是对底层的系统返回了一个失败,这里涉及到多个系统的沟通成本,基本上半天的时间就没了。

SOA vs 微服务

挑战

微服务的挑战可以概述如下:

  • API Gateway
  • 服务间调用
  • 服务发现
  • 服务容错
  • 服务部署
  • 数据调用

不过幸运的是,很多成熟的中间件,已经为我们解决了这些问题。

第一代微服务框架

dubbo 的架构

Dubbo 的架构如下:

技术架构的演进之路:为什么需要微服务?

dubbo 针对 rpc 这部分做的很好,单也仅此而已。

但是为什么还是会这么火爆呢?

很多架构的升级都会有历史包袱,除非你是一家新公司,全新的应用。

大部分的应用都是 spring 或者 springboot 的,所以现在大部分公司都是 springboot + dubbo 的技术选型方案,这样可以让架构的平滑的迁移。

如果你们公司是全新的技术选型,可以考虑 spring cloud。

spring cloud 架构

你会发现 spring cloud 可以说是 java 技术栈中,比较完善的微服务框架。

当然,spring 再牛,负责的声明周期也只是 jvm 之内,应用的部署运维也是需要考虑的。

每一项技术都有其优势和局限性,所以需要结合使用。

推荐阅读:

Microservice Architectures With Spring Cloud and Docker

目前 docker 虚拟化技术如日中天,结合 k8s 掌托。

我选称这盛世为,喝不起咖啡的打工人,在春天的货船上,996 搬砖!

下一代微服务:Service Mesh?

Service Mesh 也是目前比较火爆的技术,我们后续进行详解。

个人感悟

技术架构的演进和生物的进化是类似的,物竞天择,适者生存。

学习技术也不能只局限于现在这一刻,要学会去回顾技术的历史,知道为什么是这样?如果有能力,也可以引领技术的未来,为什么不是这样呢?

我觉得自己很幸运,最初接触的是单体应用,是 spring xml 配置的时代。

我觉得自己很不幸,框架层出不穷,技术日新月异,如果不持续学习,不出 5 年,就会被彻底淘汰。

为了不被那么快淘汰,本系列将从微服务的发展历史,理论知识,入门使用,应用实战,实现原理,重复造轮子等方面,逐渐理解微服务。

 

责任编辑:姜华 来源: 今日头条
相关推荐

2016-01-20 09:54:51

微服务架构设计SOA

2024-06-03 10:19:05

2020-11-25 09:56:48

架构运维技术

2023-12-30 08:27:13

2023-01-11 16:22:07

2022-05-25 08:00:00

开发微服务企业

2024-06-05 12:03:43

微服务架构场景

2023-10-11 07:29:21

2023-09-15 12:30:06

微服务架构管理

2020-02-04 14:41:37

微服务设计DDD

2020-07-10 15:18:12

微服务设计模型

2017-03-06 17:30:11

微服务架构系统

2024-04-24 07:00:00

Redis架构数据持久化

2024-05-16 07:51:55

分布式系统架构

2020-09-01 10:46:55

微服务架构服务器

2023-11-21 08:37:09

2020-07-10 08:27:55

王者荣耀微服务架构

2020-09-07 09:55:04

技术资讯

2016-03-15 16:24:47

集群调度框架演进

2015-02-03 09:36:45

微服务2015元年
点赞
收藏

51CTO技术栈公众号