《微服务学习笔记》由会员分享，可在线阅读，更多相关《微服务学习笔记（9页珍藏版）》请在金锄头文库上搜索。
1、百度文库 - 让每个人公平地提升自我微效劳学习笔记一什么是六边形架构“六边形架构”是 Cockburn 大牛在2005 年 提出的。该架构供给了一种将业务规律和具体输入输出技术分别的模式。为什么承受微效劳现在大多数开发一个应用，哪怕是类似 Uber 或者淘宝的应用。根本上都是已单体模式开发。虽然在应用自身架构上承受了模块化设 计，但在本质上他还是一个单体应用。例如：如以下图这样的单体应用不好吗？上图，是比较经典优秀的单体六边形架构。在很多公司实际上由于各种缘由单体应用架构还没有到达这个水平。所以会有以下几个方面问题 1. 整体扩展性差，当应用越来越浩大后，进展新功能开发或者功能修改将会很困难。
2、2. 整体耦合度高，一样当应用浩大。解耦将是一个叫你头疼的问题。3. 简单度高，维护性差。当他足够浩大。新来的同事将会接手一个对他们看来是个怪物的东西，你会听到这些埋怨。这都是什么？你们到底在想什么？4. 性能低下，由于各种缘由，主要是开发人员水平不一。你会觉察整个应用越来越慢，你想找到缘由变的越来越困难。代码有大量沉余，你每天都在纠结是否可以重建他不是重构！。为什么要承受微效劳？不能直接承受比较高级的架构吗？微效劳实际上就是用多个单体应用的集合。用多个单体效劳来处理一些简单业务。在实际开发中，除了架构师，9对单个开发人员来说他只是需要开发一个简洁的单体应用。开发门槛比较低，你以为在成都，西安
3、等这些二三线城市高 水平的程序员是那么好找的吗？二三线小城市公司开不起 工资，理解高级架构的高级程序员至少 20，30K 工资。综上，微效劳将是解决二三线小城市，小公司问题的一个优秀 方案。什么是微效劳？微效劳开发团队怎么组建？上文已经说了，微效劳实际就是多个单体应用的集合。那么一个微 效劳开发团队需要那些人员呢？下面我就说下我的理解。一 个微效劳最小开发团队：首先明确开发根底环境。既然微效劳了。那么你的应用已经不是一个简洁的效劳可以满足 需求或者你设想中的业务是需要一个效劳平台才能解决的。 那么最小配置将需要以下岗位。工程经理：他会负责产品开发进度把控等等。优秀的工程经理打算你团队的战斗力。
4、产品经理：一个优秀的产品经理可以快速把你的想法或者用户的需要准确形成各种需求，他是不行或缺的。架构师： 一个精通各种设计理论，有丰富一线开发阅历并且了解微效劳的架构师他将是整个团队的核心。打算你整个 产品的质量。核心高级工程师： 他将会负责整个微效劳开发门槛最高的 API Gateway 效劳的人选。他的好坏直接打算你的产品性能。高级工程师： 他是带着开发小组进展具体开发的人选。他打算了代码质量和单个单体应用的性能。学校级工程师： 他们将是大多数具体功能开发者。在高级工程师的指导下开发出符合要求的代码，同时也是公司的后备人才，人才储藏。微效劳的架构是什么？我先呈现一个最粗粒度的微效劳架构，然后
5、我们在一起一步一步 完善它。为什么承受 API Gateway？对应用来说，不管你怎么变化技术。实际处理的业务可以抽象成一句话，客户端 恳求效劳返回数据并向客户呈现。客户端与效劳端的通信我 们常见的有两种方式。1. 客户端直接跟效劳端通信。2. 客户端通过 API Gateway 跟效劳端通信。理论上说，一个客户端可以直接给多个微效劳中的任何一个发起恳求。每一 个微效劳都会有一个对外效劳端。这个 URL 可能会映射到微效劳的负载均衡上，它再转发恳求到具体节点上。为了搜寻 产品细节，移动端需要向上述微效劳逐个发恳求。不幸的是，这个方案有很多困难和限制。其中一个问题是客 户端的需求量与每个微效劳暴
6、露的细粒度 API 数量的不匹配。如图中，客户端需要 7 次单独恳求。在更简单的场景中， 可能会需要更屡次恳求。例如，亚马逊的产品最终页要恳求数百个微效劳。虽然一个客户端可以通过 LAN 发起很多个恳求，但是在公网上这样会很没有效率，这个问题在移动互联网上尤为突出。这个方案同时会导致客户端代码格外简单。另一个存在的问题是客户端直接恳求微效劳的协议可能并不是 web 友好型。一个效劳可能是用 Thrift 的 RPC 协议，而另一个效劳可能是用 AMQP 消息协议。它们都不是扫瞄或防火墙友好的，并且最好是内部使用。应用应当在防火墙外采用类似 或者 WEBSocket 协议。这个方案的另一个缺点是
7、它很难重构微效劳。随着时间的推 移，我们可能需要转变系统微效劳目前的切分方案。例如， 我们可能需要将两个效劳合并或者将一个效劳拆分为多个。 但是，假设客户端直接与微效劳交互，那么这种重构就很难 实施。由于上述三种问题的缘由，客户端直接与效劳器端通信的方式很少在实际中使用。通常来说，一个更好的解决方法是承受 API Gateway 的方式。API Gateway 是一个效劳器，也可以说是进入系统的唯一节点。这跟面对对象设计模式中的Facade 模式很像。API Gateway 封装内部系统的架构，并且供给 API 给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、恳求分片和治理、静
8、态响应处理等。API Gateway 负责恳求转发、合成和协议转换。全部来自客户端的恳求都要先经过 API Gateway，然后路由这些恳求到对应的微效劳。API Gateway 将经常通过调用多个微效劳来 处理一个恳求以及聚合多个效劳的结果。它可以在 web 协议与内部使用的非 Web 友好型协议间进展转换，如 协议、WebSocket 协议。API Gateway 可以供给应客户端一个定制化的 API。它暴露一个粗粒度 API 给移动客户端。以产品最终页这个使用场景为例。API Gateway 供给一个效劳供给点/productdetails?productid=xxx使得移动客户端可以在
9、一 个恳求中检索到产品最终页的全部数据。API Gateway 通过调用多个效劳来处理这一个恳求并返回结果，涉及产品信息、推举、评论等。一个很好的 API Gateway 例子是 Netfix API Gateway。Netflix 流效劳供给数百个不同的微效劳，包括电视、机顶盒、智能手机、玩耍系统、平板电脑等。起初，Netflix 视图供给一个适用全场景的 API。但是，他们觉察这种形式不好用，由于 涉及到各式各样的设备以及它们独特的需求。现在，他们承受一个 API Gateway 来供给容错性高的 API，针对不同类型设备有相应代码。事实上，一个适配器处理一个恳求平均要调用 6 到 8 个
10、后端效劳。Netflix API Gateway 每天处理数十亿的恳求。API Gateway 的优点和缺点如你所料，承受 API Gateway 也是优缺点并存的。API Gateway 的一个最大好处 是封装应用内部构造。相比起来调用指定的效劳，客户端直接跟 gatway 交互更简洁点。API Gateway 供给应每一个客户端一个特定 API，这样削减了客户端与效劳器端的通信次数， 也简化了客户端代码。API Gateway 也有一些缺点。它是一个高可用的组件，必需要开发、部署和治理。还有一个问题，它可能成为开发的一 个瓶颈。开发者必需更新 API Gateway 来供给新效劳供给点来支
11、持新暴露的微效劳。更新 API Gateway 时必需越轻量级越好。否那么，开发者将由于更新 Gateway 而排队列。但是， 除了这些缺点，对于大局部的应用，承受 API Gateway 的方式都是有效的。实现一个 API Gateway 既然我们已经知道了承受 API Gateway 的动机和优缺点，下面来看在设计它时需要考虑哪些事情。性能和可扩展性只有少数公司需要处理像Netflix 那样的规模，每天需要处理数十亿的恳求。但是，对于大多数应用，API Gateway 的性能和可扩展性也是格外重 要的。因此，创立一个支持同步、非堵塞 I/O 的 API Gateway 是有意义的。已经有不
12、同的技术可以用来实现一个可扩展的API Gateway。在JVM 上，承受基于NIO 技术的框架，如Netty， Vertx，Spring Reactor 或者 JBoss Undertow。Node.js 是一个非 JVM 的流行平台，它是一个在 Chrome 的 JavaScript 引擎根底上建立的平台。一个可选的方案是 NGINX Plus。NGINX Plus 供给一个成熟的、可扩展的、高性能 web 效劳器和反向代理，它们均简洁部署、配置和二次开发。NGINX Plus 可以治理授权、权限把握、负载均衡、缓存并供给应用安康检查和监控。承受反响性编程模型对于有些恳求，API Gate
13、way 可以通过直接路由恳求到对应的后端效劳上的方式来处理。对于另外一些恳求，它需要调用多个后端效劳并合并结果来处理。对于一些恳求，例如产品最终页面恳求，发给后端效劳的恳求是相互独立的。为了最小化响应时间，API Gateway应当并发的处理相互独立的恳求。但是，有时候恳求之间是有依靠的。API Gateway 可能需要先通过授权效劳来验证恳求，然后在路由到后端效劳。类似的，为了获得客户的产品 愿望清单，需要先猎取该用户的资料，然后返回清单上产品 的信息。这样的一个 API 组件是 Netflix Video Grid。利用传统的同步回调方法来实现 API 合并的代码会使得你进入回调函数的噩梦
14、中。这种代码将格外难度且难以维护。一个优雅的解决方案是承受反响性编程模式来实现。类似的反响抽象实现有 Scala 的 Future，Java8 的 CompletableFuture 和 JavaScript 的 Promise。基于微软.Net 平台的有 Reactive Extensions(Rx)。Netflix 为 JVM 环境创立了 RxJava 来使用他们的 API Gateway。同样地，JavaScript 平台有 RxJS，可以在扫瞄器和 Node.js 平台上运行。承受反响编程方法可以挂念快速实现一个高效的 API Gateway 代码。效劳调用一个基于微效劳的应用是一个分
15、布式系统，并且必需承受线程间通信的机制。有两种线程间通信的方法。一种是承受异步机制， 基于消息的方法。这类的实现方法有 JMS 和 AMQP。另外的， 例如 Zeromq 属于效劳间直接通信。还有一种线程间通信承受同步机制，例如 Thrift 和 。事实上一个系统会同时承受同步和异步两种机制。由于它的实现方式有很多种，因此API Gateway 就需要支持多种通信方式。效劳觉察 API Gateway 需要知道每一个微效劳的 IP 和端口。在传统应用中，你可能会硬编码这些地址，但是在现在云根底的微效劳应用中，这将是个简洁的问题。根底效劳通常会承受静态地址， 可以承受操作系统环境变量来指定。但是
16、，探测应用效劳的 地址就没那么简洁了。应用效劳通常动态安排地址和端口。 同样的，由于扩展或者升级，效劳的实例也会动态的转变。 因此，API Gateway 需要承受系统的效劳觉察机制，要么承受效劳端觉察，要么是客户端觉察。后续的一篇文章将会更 具体的介绍这局部。假设承受客户端觉察效劳，API Gateway 必需要去查询效劳注册处，也就是微效劳实例地址的数据 库。处理局部失败在实现 API Gateway 过程中，另外一个需要考虑的问题就是局部失败。这个问题发生在分布式系统中 当一个效劳调用另外一个效劳超时或者不行用的状况。API Gateway 不应当被阻断并处于无限期等待下游效劳的状态。但是，如何处理这种失败依靠于特定的场景和具体效劳。例 如，假设是在产品详情页的推举效劳模块无响应，那么 API Gateway 应当返回剩下的其他信息给用户，由于这些信
