微服务(Microservices)和服务网格(Service Mesh)架构概念整理

微服务(Microservices)

在过去的 2016 年和 2017 年,微服务技术迅猛普及,和容器技术一块儿成为这两年中最吸引眼球的技术热点。而以 Spring Cloud 为表明的传统侵入式开发框架,占据着微服务市场的主流地位。git

微服务(Microservices)是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每一个微服务仅关注于完成一件任务并很好地完成该任务。在全部状况下,每一个任务表明着一个小的业务能力。github

形像一点来讲,微服务架构就像搭积木,每一个微服务都是一个零件,并使用这些零件组装出不一样的形状。通俗来讲,微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统,并利用简单的方法使多个小系统相互协做,组合成一个大系统。数据库

若是学科派一点,微服务架构就是把因相同缘由而变化的功能聚合到一块儿,而把因不一样缘由而变化的功能分离开,并利用轻量化机制(一般为 HTTP RESTful API)实现通讯。网络

微服务架构 ≈ 模块化开发 + 分布式计算。架构

须要注意的是“微服务”与“微服务架构”是有本质区别的。“微服务”强调的是服务的大小,它关注的是某一个点。而“微服务架构”则是一种架构思想,须要从总体上对软件系统进行通盘的考虑。负载均衡

微服务架构示意图:框架

常见的微服务组件及概念:运维

  • 服务注册:服务提供方将本身调用地址注册到服务注册中心,让服务调用方可以方便地找到本身。
  • 服务发现:服务调用方从服务注册中心找到本身须要调用的服务的地址。
  • 负载均衡:服务提供方通常以多实例的形式提供服务,负载均衡功能可以让服务调用方链接到合适的服务节点。而且,节点选择的工做对服务调用方来讲是透明的。
  • 服务网关:服务网关是服务调用的惟一入口,能够在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
  • 配置中心:将本地化的配置信息(properties, xml, yaml 等)注册到配置中心,实现程序包在开发、测试、生产环境的无差异性,方便程序包的迁移。
  • API 管理:以方便的形式编写及更新 API 文档,并以方便的形式供调用者查看和测试。
  • 集成框架:微服务组件都以职责单一的程序包对外提供服务,集成框架以配置的形式将全部微服务组件(特别是管理端组件)集成到统一的界面框架下,让用户可以在统一的界面中使用系统。
  • 分布式事务:对于重要的业务,须要经过分布式事务技术(TCC、高可用消息服务、最大努力通知)保证数据的一致性。
  • 调用链:记录完成一个业务逻辑时调用到的微服务,并将这种串行或并行的调用关系展现出来。在系统出错时,能够方便地找到出错点。
  • 支撑平台:系统微服务化后,系统变得更加碎片化,系统的部署、运维、监控等都比单体架构更加复杂,那么,就须要将大部分的工做自动化。如今,能够经过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点,以咱们两年的实践经验,能够这么说,若是没有合适的支撑平台或工具,就不要使用微服务架构。

微服务架构的优势:分布式

  • 下降系统复杂度:每一个服务都比较简单,只关注于一个业务功能。
  • 松耦合:微服务架构方式是松耦合的,每一个微服务可由不一样团队独立开发,互不影响。
  • 跨语言:只要符合服务 API 契约,开发人员能够自由选择开发技术。这就意味着开发人员能够采用新技术编写或重构服务,因为服务相对较小,因此这并不会对总体应用形成太大影响。
  • 独立部署:微服务架构可使每一个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改能够在测试经过后当即部署。因此微服务架构也使得 CI/CD 成为可能。
  • Docker 容器:和 Docker 容器结合的更好。
  • DDD 领域驱动设计:和 DDD 的概念契合,结合开发会更好。

微服务架构的缺点:模块化

  • 微服务强调了服务大小,但实际上这并无一个统一的标准:业务逻辑应该按照什么规则划分为微服务,这自己就是一个经验工程。有些开发者主张 10-100 行代码就应该创建一个微服务。虽然创建小型服务是微服务架构崇尚的,但要记住,微服务是达到目的的手段,而不是目标。微服务的目标是充分分解应用程序,以促进敏捷开发和持续集成部署。
  • 微服务的分布式特色带来的复杂性:开发人员须要基于 RPC 或者消息实现微服务之间的调用和通讯,而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的至关棘手。
  • 分区的数据库体系和分布式事务:更新多个业务实体的业务交易至关广泛,不一样服务可能拥有不一样的数据库。CAP 原理的约束,使得咱们不得不放弃传统的强一致性,而转而追求最终一致性,这个对开发人员来讲是一个挑战。
  • 测试挑战:传统的单体WEB应用只需测试单一的 REST API 便可,而对微服务进行测试,须要启动它依赖的全部其余服务。这种复杂性不可低估。
  • 跨多个服务的更改:好比在传统单体应用中,如有 A、B、C 三个服务须要更改,A 依赖 B,B 依赖 C。咱们只需更改相应的模块,而后一次性部署便可。可是在微服务架构中,咱们须要仔细规划和协调每一个服务的变动部署。咱们须要先更新 C,而后更新 B,最后更新 A。
  • 部署复杂:微服务由不一样的大量服务构成。每种服务可能拥有本身的配置、应用实例数量以及基础服务地址。这里就须要不一样的配置、部署、扩展和监控组件。此外,咱们还须要服务发现机制,以便服务能够发现与其通讯的其余服务的地址。所以,成功部署微服务应用须要开发人员有更好地部署策略和高度自动化的水平。
  • 总的来讲(问题和挑战):API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用。

不过,如今不少微服务的框架(好比 Spring Cloud、Dubbo)已经很好的解决了上面的问题。

 

服务网格(Service Mesh)

2017 年末,非侵入式的 Service Mesh 技术从萌芽到走向了成熟。

Service Mesh 又译做“服务网格”,做为服务间通讯的基础设施层

若是用一句话来解释什么是 Service Mesh,能够将它比做是应用程序或者说微服务间的 TCP/IP,负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来讲通常无须关心 TCP/IP 这一层(好比经过 HTTP 协议的 RESTful 应用),一样使用 Service Mesh 也就无须关系服务之间的那些原来是经过应用程序或者其余框架实现的事情,好比 Spring Cloud、OSS,如今只要交给 Service Mesh 就能够了。

Service Mesh 的前因后果:

  1. 从最原始的主机之间直接使用网线相连
  2. 网络层的出现
  3. 集成到应用程序内部的控制流
  4. 分解到应用程序外部的控制流
  5. 应用程序的中集成服务发现和断路器
  6. 出现了专门用于服务发现和断路器的软件包/库,如 Twitter 的 Finagle 和 Facebook 的 Proxygen,这时候仍是集成在应用程序内部
  7. 出现了专门用于服务发现和断路器的开源软件,如 Netflix OSS、Airbnb 的 synapse 和 nerve
  8. 最后做为微服务的中间层 Service Mesh 出现

Service Mesh 有以下几个特色:

  • 应用程序间通信的中间层
  • 轻量级网络代理
  • 应用程序无感知
  • 解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh 架构图:

目前流行的 Service Mesh 开源软件有 Linkerd、Envoy 和 Istio,而最近 Buoyant(开源 Linkerd 的公司)又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit。

Service Mesh 开源项目简介:

  • Linkerdhttps://github.com/linkerd/linkerd):第一代 Service Mesh,2016 年 1 月 15 日首发布,业界第一个 Service Mesh 项目,由 Buoyant 创业小公司开发(前 Twitter 工程师),2017 年 7 月 11 日,宣布和 Istio 集成,成为 Istio 的数据面板。
  • Envoyhttps://github.com/envoyproxy/envoy):第一代 Service Mesh,2016 年 9 月 13 日首发布,由 Matt Klein 我的开发(Lyft 工程师),以后默默发展,版本较稳定。
  • Istiohttps://github.com/istio/istio):第二代 Service Mesh,2017 年 5 月 24 日首发布,由 Google、IBM 和 Lyft 联合开发,只支持 Kubernetes 平台,2017 年 11 月 30 日发布 0.3 版本,开始支持非 Kubernetes 平台,以后稳定的开发和发布。
  • Conduithttps://github.com/runconduit/conduit):第二代 Service Mesh,2017 年 12 月 5 日首发布,由 Buoyant 公司开发(借鉴 Istio 总体架构,部分进行了优化),对抗 Istio 压力山大,也期待 Buoyant 公司的毅力。
  • nginMeshhttps://github.com/nginmesh/nginmesh):2017 年 9 月首发布,由 Nginx 开发,定位是做为 Istio 的服务代理,也就是替代 Envoy,思路跟 Linkerd 以前和 Istio 集成很类似,极度低调,GitHub 上的 star 也只有不到 100。
  • Konghttps://github.com/Kong/kong):比 nginMesh 更加低调,默默发展中。

关于微服务和服务网格的区别,个人一些理解:微服务更像是一个服务之间的生态,专一于服务治理等方面,而服务网格更专一于服务之间的通讯,以及和 DevOps 更好的结合

相关文章
相关标签/搜索