【微服务专题】深入理解与实践微服务架构(二)之微服务架构的历史演进

Java白羊
535 阅读13分钟

我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第3篇文章，点击查看活动详情

单体架构

单体架构 -- 架构的初始形态

传统的单体架构，也就是单点应用，采用分层架构模式（数据库访问层、业务逻辑层、控制层）。从前端到后端所有的代码都是一个工程中写的，部署在同一个tomcat中。

  • 优点：开发简单、运维简单。

  • 缺点：

    • 如果系统中某个模块出现了不可用，会导致整个系统无法使用；
    • 功能复杂的应用，会增加系统的耦合性，增加开发的复杂度。

但随着系统业务模块的增多，系统变得越来越复杂，维护麻烦的单体架构，逐渐被其他更解耦和扩展度更好的架构所取代。

SOA架构

SOA架构 -- 微服务架构的先驱

SOA架构是微服务架构的前身。SOA面向服务架构是基于分布式架构模式演变而来，俗称服务化，也就是面向接口开发(服务开发)。将共同存在的业务逻辑抽取成一个共同的服务（只有接口没有控制层和视图层，也就是只有service和dao层），提供给其他的服务接口实现调用、服务与服务之间通讯采用rpc远程调用技术，可以解决代码冗余性问题。

SOA架构是面向服务架构的意思，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

可以说SOA架构提供了服务化、服务提供者和服务请求者的思想的先河，为后面微服务的服务模块化和生产者-消费者模型提供了架构参考。主要内容如下：

1、服务请求者(消费者) ：服务请求者是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。服务请求者根据接口契约来执行服务。

2、服务提供者(生产者) ：服务提供者是一个可通过网络寻址的实体，它接受和执行来自请求者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务请求者可以发现和访问该服务。

3、服务注册中心：服务注册中心是服务发现的支持者。它包含一个可用服务的存储库，并允许感兴趣的服务请求者查找服务提供者接口。

面向服务的体系结构中的每个实体都扮演着服务提供者、请求者和注册中心这三种角色中的某一种(或多种)。面向服务的体系结构中的操作包括:

  • 发布：为了使服务可访问.需要发布服务描述以使服务请求者可以发现和调用它。
  • 查询：服务请求者定位服务.方法是查询服务注册中心来找到满足其标准的服务。
  • 绑定和调用：在检索完服务描述之后，服务请求者继续根据服务描述中的信息来调用服务。
特点缺点
1、SOA架构模式传输协议采用SOAP协议(http/https+XML)实现传输，在高并发情况下会存在大量的冗余性传输，非常占用带宽，所以微服务框架用json替代了xml。1、采用SOAP协议实现通讯，xml传输非常重，效率比较低，而且很占带宽
2、SOA架构模式实现方案为WebService或者是ESB企业服务总线 底层通讯协议SOAP协议（Http+XML）实现传输。2、服务化管理和治理设施不够完善
3、ESB企业服务总线（数据协议的转换，解决多系统之间跨语言通讯，提供可靠消息传输。）3、依赖于中心服务发现机制
4、SOAP简单对象访问协议4、不适合于前后端分离架构模式

微服务架构

微服务架构 -- 模块化的服务架构

“微服务架构是一种架构模式，它提倡将单一应用程序拆分为一组微服务，服务之间相互协调、互相配合，为用户提供最终价值。

每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

另外，在微服务中，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

image-20220422155241605

在微服务的概念中，微服务的主要划分为以下几大模块：

  • 服务注册与发现模块
  • 服务监控模块
  • 服务容错模块
  • 服务安全模块
  • 服务治理模块

引入以上几大服务治理模块之后，对于应用有利也有弊：

优点

  1. 提升开发交流，每个服务足够内聚，足够小，代码容易理解；
  2. 服务独立测试、部署、升级、发布；
  3. 按需定制的DFX，资源利用率，每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；每个服务按
  4. 需要选择HA的模式，选择接受服务的实例个数；
  5. 容易扩大开发团队，可以针对每个服务（service）组件开发团队；
  6. 提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；
  7. 新技术的应用，系统不会被长期限制在某个技术栈上。

缺点

技术没有绝对的银弹，微服务在解决系统功能耦合与复杂度的同时，也提高了系统开发的复杂度。

  1. 开发人员要处理分布式系统的复杂性；
  2. 服务之间的分布式通信问题；
  3. 服务的注册与发现问题；
  4. 服务之间的分布式事务问题；
  5. 数据隔离再来的报表处理问题；
  6. 服务之间的分布式一致性问题；
  7. 服务管理的复杂性，服务的编排；
  8. 不同服务实例的管理。

主要体现在：

  • 微服务的划分

微服务的划分主要是保证微服务功能高内聚、低耦合和职责单一。一般需要对微服务进行模块划分，这种方法有点类似于数据库ER图的划分，不断分解数据，保证关系型数据库符合原子性、冗余性的范式要求。当然，微服务的划分比数据表划分更复杂，也没有微服务范式的概念，但思想是一致的。

  • 分布式一致性

主要有两个方面：分布式事务、缓存一致性和最终一致性

  1. 分布式事务体现在数据库之间的数据修改过程中，保证本地事务和远程事务的一致性；
  2. 缓存一致性体现在数据库使用缓存进行数据查询，修改数据库数据后，保证缓存的数据同步修改的一致性问题；
  3. 最终一致性体现在消息队列对已经发起的动作，可以是缓存也可以是任务，通过订阅异步通知的方式最终实现一致性的问题。
  • 数据隔离问题

微服务之间数据隔离可以保证服务的独立升级与部署，数据隔离有三个维度：

  1. 数据表级隔离；数据表之间独立，没有外键关系；
  2. 数据库级隔离；不同服务有不同的数据库；
  3. DBMS级隔离；不同服务有不同的数据库管理系统；

一般做到数据库级隔离就可以了，服务之间的数据交换使用服务间接口。

SOA与微服务架构的区别与联系

首先SOA架构和微服务架构其实是一个层面的东西，因为SOA架构是微服务架构的前身。

从服务拆分，谈SOA与微服务的区别与联系

在服务拆分中，业务系统实施服务化改造之后，原本共享的业务被拆分成可共享的服务。服务拆分，可以在最大程度上避免共享业务的重复建设和资源连接瓶颈等问题。那么被拆分出来的服务，是否也需要以业务功能为维度来进行拆分和部署，以降低业务的耦合及提高容错性呢？

微服务就是这样一种解决方案，从名字上看，SOA(面向服务的架构)和微服务本质上都是服务化思想的一种体现。

如果SOA是面向服务化开发思想的雏形，那么微服务就是针对可重用业务服务的进一步优化，我们可以把SOA看成微服务的超集，一旦服务规模扩大就意味着服务的构建、发布、运维的复杂度也会成倍的增加，所以实施微服务的前提是软件交付链路及基础设施的成熟化，因此微服务在我看来并不是一个新的概念，它本质上是服务化思想的最佳实践方向，由于SOA和微服务两者的关注点不一样，造成了两者具有非常大的区别。 比如SOA架构中的ESB企业服务总线和微服务中的网关就不是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。

关于SOA和微服务架构的区别和联系，个人的一些理解：

  • SOA（Service Oriented Architecture，面向服务的架构）：他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在于操作系统进程中。各个服务之间 通过网络调用。
  • 微服务架构：其实和 SOA 架构类似，微服务是在SOA上做的升华。微服务架构强调的一个重点是"业务需要彻底的组件化和服务化"，也就是去中心化的服务。原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用，这些小应用之间通过服务完成交互和集成。

从SOA与微服务架构的特点，谈SOA与微服务的区别与联系

SOA架构特点：

  • 系统集成： 站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范。这一步解决的核心问题是有序；
  • 系统的服务化： 站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的是把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。这一步解决的核心问题是复用；
  • 业务的服务化： 站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力，前面两步都是从技术层面来解决系统调用、系统功能复用的问题。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是高效。

微服务架构特点：

  • 服务组件化：开发者不再需要协调其它服务部署对本服务的影响。

  • 按业务能力来划分服务和开发团队：开发者可以自由选择开发技术，提供API服务。

  • 去中心化

    • 每个微服务有自己私有的数据库持久化业务数据。
    • 每个微服务只能访问自己的数据库，而不能访问其它服务的数据库。
    • 某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
    • 数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

  • 基础设施自动化（devops、自动化部署） ：Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多，不集中管理就无法实现DevOps中间过程的完全打通）。

因此，SOA和微服务架构的主要差别，在以下几个方面：

  • 微服务去中心化，去掉ESB企业总线。微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。
  • Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Node或者Spring Boot等技术跑在自己的进程中。
  • SOA注重的是系统集成方面，而微服务关注的是业务完全分离。

欢迎点赞，谢谢大佬ヾ(◍°∇°◍)ﾉﾞ

avatar
文章
阅读
粉丝