微服务浅析

服务端架构的演进

一般来说,早期的软件大多数是单体架构,接着使用分层技术演化为垂直架构,然后 SOA 面向服务架构和微服务架构相继登场,最终随着云技术的应用和推广而孕育出云原生架构的思想。下面我们就来一一介绍这些架构设计的基础理念和优缺点。

单体架构

在 Web 应用程序发展的早期,大部分工程是将所有的服务端功能模块打包成单个巨石型(Monolith)应用,譬如很多企业的 Java 应用程序打包为 war 包,最终会形成如下图所示的架构。

单体架构的应用程序

单体架构的应用开发简单,技术单一,测试、部署相对简单明了。但其缺陷也是非常明显的,进行局部改动就需要重新部署,而且编译时间过长。除此之外,单体架构的技术栈也不易扩展,只能不断地在原有基础上进行局部优化,比如说应用的某一场景需要处理高并发,使用 Go 语言较为合适,但是单体架构并不支持多语言技术栈,这时也就只好作罢。

垂直分层架构

单体架构在系统用户访问量逐渐增大的情况下,若仅仅依靠扩展物理机配置或者增加机器来优化系统的性能,往往收效甚微。单体架构中不同业务模块的差异就会显现,比如有些模块是 IO 密集型,有些是计算密集型。这些模块所需要的机器数量和性能各有差异,这时为了提升机器利用率和性能,垂直分层架构就诞生了。

垂直分层架构是将大应用拆分成一个个单体结构的应用。换句话说,垂直架构就是彼此存在依赖关系的组件组成的架构,比如分层——用户界面层依赖业务逻辑,而业务逻辑依赖数据库访问(如下图所示)。垂直分层是一个典型的对复杂系统进行结构化思考和抽象聚合的通用性方法。

垂直分层架构的应用程序

这样处理后,垂直分层架构就解决了很多问题:将系统拆分实现了流量分担,解决了部分并发问题;拆分之后,服务间相互独立;性能方面,可以针对单个服务模块进行优化;易于水平扩展,多实例提升容错率。

但其缺点也是明显的,垂直分层架构的系统拆分,使得集群搭建变得复杂;涉及的服务间调用,服务之间耦合度变高,调用关系错综复杂,难以维护调用关系。

SOA 面向服务架构

当垂直架构拆分的应用越来越多时,就会出现多个应用都依赖的业务逻辑组件,并且各个应用进行交互的需要也越来越频繁。此时,就需要将部分通用的业务组件独立出来,并定义好服务间交互的接口,向外提供能力,让其他服务调用。SOA 面向服务架构这就“应运而生”了。

SOA 面向服务架构是一种软件体系结构,它将应用程序的不同服务通过定义良好的接口和契约联系起来,这些接口独立定义,不依赖实现服务的编程语言、操作系统。应用程序的不同组件通过网络上的通信协议向其他组件提供服务。通信可以是简单的数据传递,也可以是两个或多个服务彼此协调连接。

SOA 面向服务架构

SOA 面向服务架构中主要有两个角色:服务提供者和使用者。如上图所示,服务消费者可以通过发送消息来调用订单、购买、账号的服务,这些消息由服务总线转换后发送给对应的服务,实现 SOA 服务之间的交互通信。

SOA 面向服务架构主要适用于大型软件服务企业对外提供服务的场景,至于一般业务场景就并不适用了,因为其服务的定义、注册和调用都需要较为烦琐的编码或者配置实现,并且业务总线也容易导致系统的单点风险并拖累整体性能。

微服务架构

随着互联网浪潮的来临,越来越多的中小微企业推出面向普通大众的网站或者应用。这些企业不同于大型软件服务企业,没有能力也无须构建 SOA 所依赖的 ESB 企业服务总线。于是继承 SOA 众多优点和理念的微服务架构于 2014 年由 Matrin Fowler 提出,其理念是将业务系统彻底地组件化和服务化,形成多个可以独立开发、部署和维护的服务或者应用的集合,以应对更快的需求变更和更短的开发迭代周期。

微服务也是一种架构风格,它提倡将大型复杂软件应用划分成多个微服务,这些服务之间互相协调、配合,可独立部署;服务之间松耦合,每个服务代表着一个小的业务能力(如下图所示)。

常见的微服务架构图

总体来说,微服务架构有如下的特点:

  • 微服务遵循单一原则,每个微服务负责一个独立上下文边界;
  • 微服务架构提供的服务之间采用 RESTful 等轻量协议传输,相比 ESB 更轻量;
  • 每个服务都有自己独立的业务开发活动和周期;
  • 微服务一般使用容器技术独立部署,运行在自己的独立进程中,合理分配其所需的系统资源,这样开发者就可以更加方便地制定每个服务的优化方案,提高系统可维护性。

但是,微服务架构也会遇到这样或那样的问题。比如,微服务架构拆分的服务实例过多的话,服务治理成本将会极大升高,不利于系统维护;服务之间相互依赖,有可能形成复杂的依赖链条,往往单个服务异常,其他服务都会受到影响,出现服务雪崩效应;服务实例之间交互需要处理分布式事务、调用幂等性和重试等问题,开发成本高,对团队挑战大。

微服务有哪些优势与劣势

优势

  1. 应用小,可快速编译部署
  2. 单个微服务维护性变高,修改容易,因为每个团队独立负责一块功能。新功能交付变快,可以快速开发交付
  3. 扩展性变高,根据业务规模可以随时缩减/增加服务器规模
  4. 可靠性变强,可以部署很多独立的服务
  5. 业务解耦,按照业务边界拆分为多个独立的服务模块
  6. 提升研发效率,业务拆分后,服务模块变小,在一个团队内就可以独立编写、测试、发布,加快研发效率。

微服务有这么多优势,那微服务是“银弹”吗?微服务不是银弹,它带来了很多优势,同时也带来了很多劣势(问题)。

劣势

  1. 整体复杂度变高,从哪些方面来管理这种复杂度?
  2. 运维变得复杂:微服务变多,怎么监控所有微服务,保证服务稳定?出了问题,怎么定位问题?
  3. 服务管理:微服务变多,管理复杂度变高,治理变得复杂
  4. 测试方面的挑战:你需要结合其他的微服务来进行集成测试
  5. 分布式问题:分布式数据一致性、分布式事务
  6. 服务保障:一个服务出了问题,如何才能不影响其他服务?

总体架构图

微服务架构图

上面的总体架构图一共分了6层

  • 接入层
    也可以叫负载均衡层,把外部的流量引入到系统中来。一般负载均衡软件有nginx,lvs,还有各大云服务厂商自己的负载均衡服务。
  • 网关层
    内部接口的一些认证、安全、鉴权、过滤、限流等服务,一般处于这一层。这一层把内部的服务接口做一层安全隔离,保护内部服务,同时也可以实现一些其他需求,比如前面讲的鉴权、黑名单过滤等等需求。所以这一层在微服务架构中是很重要的一层。
  • 业务服务层
    基础服务和聚合服务
    • 基础服务:根据业务特点又可以分为核心基础服务、公共服务、中间层服务等。
    • 聚合服务:把下面细粒度的基础服务再进一步封装、关联,组合成新的服务,供上层调用。这一层可以实现多变的需求。
      上面的这种划分是根据逻辑来划分,各个公司可以根据自己实际的业务需求来进行划分。
  • 支撑服务层
    微服务能够成功实施落地,这一层与下一层CI/CD的配套设施是非常重要。微服务不是把上面的业务服务写完就完事了,在服务治理的过程中需要很多配套设置支持。
    这一层包括注册服务中心,配置中心,监控报警服务,日志聚合服务,调用链监控几大服务,后台服务涉及的服务有消息队列,定时任务,数据访问等内容。
  • 平台服务层
    这一层是实施业务弹性治理的关键。集群的资源调度:扩展和减少。业务量上来时,可以弹性增加资源。
    在微服务建设过程中,可能会遇到一些突发事件。比如微博明星热点事件,会导致访问量暴增,这就需要能实时增加服务资源应对这种突发情况,热点过后,又要减少资源。
    镜像管理和发布系统配合使用可以应对出现的这种情况。所以很多团队后面会引入docker+k8s,容器,镜像管理,容器服务编排。此外,基于CI/CD的DevOps也是构建在这一层能力。
  • 基础设施层
    这个是最底层的基础设施,网络,存储,硬盘,IDC的部分。
    laas 这个概念就是针对这一层。

微服务技术体系

技术体系

Golang微服务技术栈

微服务框架

网关

服务注册和发现

配置中心

服务治理

断路器:

流量控制:

  • sentinel-golang-从限流、流量整形、熔断降级、系统负载保护等多个维度来帮助您保障微服务的稳定性。

链路监控

zipkin,pinpoint,skywalking,jaeger

日志、业务、系统监控

prometheus
ELK

CI/CD

内容来自: