微服务浅谈

大部分公司都会经历单体应用、SOA、微服务的各个架构演变的过程。

单体应用

单体应用 是一个耦合了大量内部不可见的服务的独立系统,由于内部多个功能的耦合导致无法模块之间无法简单的拆分(牵一发而动全身)。

优缺点

优点:

  • 易于开发/调试,全部功能集中在一个项目
  • 易于测试,功能耦合在一起,没有分布式带来的诸多问题
  • 易于部署,只有一个应用

缺点:

  • 不易于开发,功能集中、内部依赖关系复杂导致系统难以开发和优化
  • 不易于持续开发迭代,整体开发、构建、部署都会影响整个迭代过程中的效率
  • 技术受限,整个应用使用相同的技术栈开发不同的功能,无法根据具体的场景做出其他选择
  • 性能瓶颈,部分功能出现瓶颈无法有针对性的优化,只能通过增加整个节点来临时解决问题(浪费资源)

@h=400

适用场景

个人博客、中小型论坛、小型门户咨询网站、个人电商系统都可以采用单体应用的方式来构建。

SOA

SOA 是一种分布式运算的软件设计方法(来自维基百科),它将应用程序的不同功能单元(称为服务)通过这些服务之间定义的接口联系起来。

SOA 是一种架构模式,是一种面向服务的思维方式

  • 服务单独部署、易于系统优化
  • 服务瓶颈单独维护和解决、易于伸缩
  • 多应用部署运维要求较高
  • 引入分布式问题:系统容错、网络延迟、分布式事务
  • 接口调整引入的问题(依赖方需要感知接口的调整)
ESB架构

企业服务总线ESB(enterprise service bus)是类似于通信模型中的通信总线的概念,所有服务应用将通过总线交互,而总线扮演着应用间的信息调度的角色,从而可以实现相互隔离的异构分布式服务系统。

@h=400

问题

  • ESB负责兼容和调度各个服务的异构接口(复杂均衡、流量控制等),内部实现很复杂
  • 所有服务共用ESB的通道,直接影响了服务的通信速度
ESB的替代品?

在Java生态中,大家常用grpcthriftdubbospring cloud

这就是第一代的微服务的具体实现,特点在于:注重服务发现、轻量链路通信。

  • 服务注册、服务发现、负载均衡均等功能都由具体的服务应用来控制
  • 服务状态信息由分布式协调服务来维护,例如zookeeper/etcd
  • 服务之间通信不再依赖一个单点总线,而是点对点的服务之间进行交互
应用场景

中大型互联网公司都在使用SOA或者微服务架构,这种架构满足互联网的快速迭代、运维自由伸缩、资源独立运维的需求。

不同团队负责不同的业务,同一业务划分不同的功能模块独立部署,从而实现快速开发、快速构建、快速部署,快速上线的要求,而且也降低了不同团队之间的耦合,大家只需要根据API接口来沟通即可,不需要关心内部实现逻辑。

微服务

从维基百科可以简单的了解一下什么是微服务

微服务 是一种软件架构风格,它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模块化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

单一职责与功能:功能独立,意味着应用可以独立部署,资源单独控制。
模块化方式组合:功能可任意组合,组合方式通过任意通信方式(通信协议)来实现,不限于RPC/Restfull。
功能区块与语言无关:应用独立部署、通信方式与语言无关,任意语言有自己的实现方式,所以应用可以采用更适合的语言来开发。

其实这里看下来,微服务和SOA是不是一样的?

较早实践微服务的公司Netflix就曾经称他们构建的架构是「细粒度的SOA」

SOA遇到kubernetes

细粒度的SOA意味着服务拆分的更细,不仅是服务拆分上的细,也是运维资源上的细

运维资源上的细可以通过K8S来实现,从而实现了第二代微服务

K8S或者说容器调度平台的引入是比较革命性的

容器使得我们的微服务对环境的依赖可以打包整合进行随意分发,从而实现微服务节点任意调度

调度平台通过服务的分类和抽象,使得微服务本身的部署和维护实现自动化,以及实现更上一层楼的自动伸缩

自动化的难点就在于服务的编排协调

虚拟化

虚拟化是指通过虚拟化技术将一台计算机虚拟为多台逻辑计算机。

VM(虚拟机)是一个物理硬件层抽象,用于将一台服务器变成多台服务器,每个VM都包含一整套操作系统、 占用大量空间、启动慢。

Docker是一个应用层抽象,用于将代码和依赖资源打包在一起。每个容器是基于已有的公共基础设施中操作系统的功能来运行的,各自作为独立的进程在用户空间中运行,占用空间极少,启动快。

Docker的轻量对于微服务来说是在适合不过了。

kubernetes

kubernetes(k8s)是用于自动部署扩展和管理容器化(containerized)应用程序的开源系统。

SOA的思想出现后,系统拆分服务会变得越来越多,单靠原有的运维方式无法支撑管理,往往需要应用开发同事来帮忙查看到底那里出现了问题(配置发生了变更?目录权限有问题?)。

基于kubernetes,运维只负责资源交付,服务的启动注册、目录权限、配置都让服务的开发者来管理,从而降低了运维的压力,而运维更能把重点转移到基础运维工作中。

kubernetes解决了服务的编排协调及快速伸缩。

虽然kubernetes为应用程序提供服务发现、负载均衡和外部路由的功能,但是大部分公司都是采用dubbo/grpc等框架来实现完整的服务发现。

Service Mesh

Service Mesh(服务网格)是一个基础设施层,用于处理服务间通信。

@h=200

Service Mesh类似于在k8s的基础之上又封装了统一的服务发现功能。

Service Mesh会接管整个集群的网络,把所有请求在服务之间做转发。从而业务开发不再需要关注服务的注册和发现,只专注完成业务逻辑,服务之间的通讯环节就从应用层剥离出来。

Service Mesh(服务网格)实际上是抽象出了一个基础设施层,独立于应用之外,所提供的功能就是实现请求的可靠路由,部署上体现为轻量级的网络代理,并对应用是透明的。

服务治理

微服务时代面临最大的挑战就是服务治理

在大型互联网公司都会有自研的一套服务治理框架,功能各不相同各有优势,但都有不足之处。

目前最火的SpringCloud提供了一系列的组件来实现微服务下的服务治理

Service Mesh(服务网格)利用基础设施层来解决服务注册、服务路由、流量控制、服务降级、安全认证等功能。

特点

对于大规模部署微服务,内部服务异构程度高的场景,使用Service Mesh(服务网格)方案是一个不错的选择。

Service Mesh(服务网格)实现了业务逻辑和控制的解耦

网络中多了一跳,增加了性能的损耗和访问的延迟

每个服务都需要部署Sidecar, 这也会使本来就具有一定复杂度的分布式系统变得更加复杂。

@h=200

现状

第一代Service Mesh的代表为LinkerdEnvoy

第二代Service Mesh主要改进集中在更加强大的控制面功能(Sidecar),典型代表有IstioConduit

到目前为止,服务网格的概念已经被实现,也有投入生产的实例,但普及还是需要一定时间。

总结

单体应用、SOA、微服务、K8S、ServiceMesh的发展中可以看到技术的层出不穷,技术分工越来越细。

参考

https://jinfei21.github.io/2018/11/15/%E6%88%91%E4%B8%BA%E4%BB%80%E4%B9%88%E7%9C%8B%E5%A5%BD%E6%96%B0%E4%B8%80%E4%BB%A3%E5%BE%AE%E6%9C%8D%E5%8A%A1ServiceMesh/
https://juejin.im/post/592f87feb123db0064e5ef7c#heading-1
https://juejin.im/post/5ad4146ff265da238670592f
https://zhuanlan.zhihu.com/p/53260098