注:文章内容为摘录性文字,自己阅读的一些笔记,方便日后查看。

微服务(Microservices)

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

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

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

如果学科派一点,微服务架构就是把因相同原因而变化的功能聚合到一起,而把因不同原因而变化的功能分离开,并利用轻量化机制(通常为 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 更好的结合

资料来源:

微服务(Microservices)和服务网格(Service Mesh)的架构概念的更多相关文章

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

    注:文章内容为摘录性文字,自己阅读的一些笔记,方便日后查看. 微服务(Microservices) 在过去的 2016 年和 2017 年,微服务技术迅猛普及,和容器技术一起成为这两年中最吸引眼球的技 ...

  2. 微服务应用新趋势:Service Mesh、AIOps和中台化

    微服务技术由于天生支持快速迭代.弹性扩展的特点,使企业能够在不确定性下提升发展速度及抗风险能力,受到了越来越多的关注.当前,云服务商纷纷试水微服务产品,最为典型的,当属推出轻舟微服务平台.剑指整个微服 ...

  3. Emoji.voto,Linkerd 服务网格(service mesh)的示例应用程序

    一个微服务应用程序,允许用户为他们最喜欢的表情符号(emoji)投票,并跟踪排行榜上收到的投票.愿最好的 emoji 获胜. 该应用程序由以下 3 个服务组成: emojivoto-web:Web 前 ...

  4. Service Mesh(服务网格)

    Service Mesh(服务网格) 什么是Service Mesh(服务网格)Service mesh 又译作 "服务网格",作为服务间通信的基础设施层.Buoyant 公司的 ...

  5. 微服务架构基础之Service Mesh

    ServiceMesh(服务网格) 概念在社区里头非常火,有人提出 2018 年是 ServiceMesh 年,还有人提出 ServiceMesh 是下一代的微服务架构基础. 那么到底什么是 Serv ...

  6. Qcon2017实录|Service Mesh:下一代微服务

    https://zhuanlan.zhihu.com/p/30292372 数人云11月Meetup报名开启,看中西方大神如何论道云原生与微服务!本文作者敖小剑老师将在本次Meetup上继续分享Ser ...

  7. Service Mesh服务网格新生代--Istio(转)

    万字解读:Service Mesh服务网格新生代--Istio  官网地址:https://preliminary.istio.io/zh/docs/concepts/security/ Servic ...

  8. 在微服务架构中service mesh是什么?

    在微服务架构中service mesh是什么 什么是 service mesh ? 微服务架构将软件功能隔离为多个独立的服务,这些服务可独立部署,高度可维护和可测试,并围绕特定业务功能进行组织. 这些 ...

  9. 浅谈服务治理、微服务与Service Mesh(三) Service Mesh与Serverless

    作为本系列文章的第三篇(前两篇<浅谈服务治理.微服务与Service Mesh(一)Dubbo的前世今生>,<浅谈服务治理.微服务与Service Mesh(二) Spring Cl ...

  10. Service Mesh架构的持续演进 单体模块化 SOA 微服务 Service Mesh

    架构不止-严选Service Mesh架构的持续演进 网易严选 王育松 严选技术团队 2019-11-25 前言同严选的业务一样,在下层承载它的IT系统架构一样要生存.呼吸.增长和发展,否则过时的.僵 ...

随机推荐

  1. node层设置proxy不生效的原因

    43服务器上pm2部署的项目,原本是想请求代理到69服务器,但是仍然代理到75服务器了,检查node层proxy代码没问题,原因是端口号被占用了,项目的5000端口被其他项目占用,5000端口实际用的 ...

  2. grep中正则表达式使用尖括号表示一个单词

    比如 grep '\<bin\>' /etc/passwd --color

  3. mysql5.7 基于gtid的主从复制

    基本环境 版本 5.7.14 主库ip:192.168.1.100 port:3306 从库ip:102.168.1.101 port:3306 搭建注意事项 主库配置 gtid-mode=on en ...

  4. ZedGraph怎样在生成曲线时随机生成不一样的颜色

    场景 在使用ZedGraph生成多条曲线时为了能区分曲线颜色,要求随机设置曲线颜色. 首先从System.Drawing.Color中获取所有颜色的对象的数组,然后将其顺序打乱随机排序,然后在生成曲线 ...

  5. jstl jsp long to date

    jsp 页面中使用jstl el 将long转换为时间类型,并格式化输出 <%@ taglib uri="http://java.sun.com/jsp/jstl/core" ...

  6. 【书上讲解】最大m段子段和问题

    描述 [题解] 设f[i][j]表示前i个数字分成了j段的最大子段和. 则f[i][j] = max(f[i-1][j]+a[i] (第i个数字和第j段合在一起),f[k][j-1]+a[i] (第i ...

  7. I - Nice to Meet You

    传送门 和10-17 B 君的第三题 类似,应该算是简化版,给出了固定的点. f[s]表示只考虑连端都在s集合中的边,s中的固定点(1或者2)能到达整个集合的方案数. 预处理c[s]表示s集合中的总边 ...

  8. NX二次开发-基于MFC界面的NX对Excel读写操作(OLE方式(COM组件))

    NX二次开发API里没有对EXCAL读写操作的相关函数,市面上有很多种方法去实现,比如UFUN调KF,ODBC,OLE(COM组件)等等.这里我是用的OLE(COM组件)方式去做的,这种在VC上创建的 ...

  9. Python内置模块-time && datatime

    Python提供两种时间表示方式,一种是时间戳,从1970年1月1日 0时开始.一种是struct_time数组格式,共有9个元素. import time print(time.time()) #返 ...

  10. contest20191023

    slz的题 KCN 雨中的晴天 宫水三叶生活的城市是一个一维平面上的城市.三叶喜欢用一个长度为n的线段来表示这座城市.线段上(包含端点)平均分布着 $n+1$ 个点,其中第 $i$ 个点到第 $i+1 ...