微服务浅谈

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

单体应用

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

优缺点

优点：

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

缺点：

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

@h=400

适用场景

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

SOA

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

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

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

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

@h=400

问题

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

在Java生态中，大家常用grpc、thrift、dubbo和spring 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的代表为Linkerd和Envoy。

第二代Service Mesh主要改进集中在更加强大的控制面功能（Sidecar），典型代表有Istio和Conduit。

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

总结

从单体应用、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