乐趣区

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

整体倒退概览

服务架构始终处于演变之中,为了适宜本人的业务,一直的去调整。

整体的倒退历程如下:

开发者视角

从一个 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 微服务

SOA 微服务架构
应用程序服务的可重用性的最大化 专一于解耦
系统性的扭转须要批改整体 系统性的扭转是创立一个新的服务
DevOps 和继续交付正在变得风行,但还不是支流 强烈关注 DevOps 和继续交付
专一于业务性能重用 更器重“上下文边界”的概念
通信应用企业服务总线 ESB 对于通信而言,应用较少精密和简略的音讯零碎
反对多种音讯协定 应用轻量级协定,例如 HTTP,REST 或 Thrift API
对部署到它的所有服务应用通用平台 应用程序服务器不是真的被应用,通常应用云平台
容器(如 Docker)的应用不太受欢迎 容器在微服务方面成果很好
SOA 服务共享数据存储 每个微服务能够有一个独立的数据存储
独特的治理和规范 轻松的治理,更加关注团队合作和抉择自在

挑战

微服务的挑战能够概述如下:

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

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

第一代微服务框架

dubbo 的架构

Dubbo 的架构如下:

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

然而为什么还是会这么火爆呢?

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

大部分的利用都是 spring 或者 springboot 的,所以当初大部分公司都是 springboot + dubbo 的技术选型计划,这样能够让架构的平滑的迁徙。

如果你们公司是全新的技术选型,能够思考 spring cloud。

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 年,就会被彻底淘汰。

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

我是老马,期待与你,一起见证开发者的春天!

退出移动版