2023年微服务学习笔记

《2023年微服务学习笔记》由会员分享，可在线阅读，更多相关《2023年微服务学习笔记（11页珍藏版）》请在装配图网上搜索。

1、微服务学习笔记（一） 什么是六边形架构 “六边形架构”是 Cockburn大牛在2023年 提出的。该架构提供了一种将业务逻辑和具体输入输出技术分离的模式。为什么采用微服务 现在大多数开发一个应用，哪怕是类似Uber或者淘宝的应用。基本上都是已单体模式开发。虽然在应用自身架构上采用了模块化设计，但在本质上他还是一个单体应用。例如：如下图这样的单体应用不好吗？ 上图，是比较经典优秀的单体六边形架构。在很多公司事实上由于各种因素单体应用架构还没有达成这个水平。所以会有以下几个方面问题1. 整体扩展性差，当应用越来越庞大后，进行新功能开发或者功能修改将会很困难。2. 整体耦合度高，同样当应用庞大。解

2、耦将是一个叫你头疼的问题。3. 复杂度高，维护性差。当他足够庞大。新来的同事将会接手一个对他们看来是个怪物的东西，你会听到这些抱怨。这都是什么？你们到底在想什么？4. 性能低下，由于各种因素，重要是开发人员水平不一。你会发现整个应用越来越慢，你想找到因素变的越来越困难。代码有大量沉余，你天天都在纠结是否可以重建他（不是重构！）。为什么要采用微服务？不能直接采用比较高级的架构吗？ 微服务事实上就是用多个单体应用的集合。用多个单体服务来解决一些复杂业务。在实际开发中，除了架构师，对单个开发人员来说他只是需要开发一个简朴的单体应用。开发门槛比较低，你认为在成都，西安等这些二三线城市高水平的程序员是那

3、么好找的吗？（二三线小城市公司开不起工资，理解高级架构的高级程序员至少20，30K工资）。 综上，微服务将是解决二三线小城市，小公司问题的一个优秀方案。什么是微服务？微服务开发团队怎么组建？ 上文已经说了，微服务实际就是多个单体应用的集合。那么一个微服务开发团队需要那些人员呢？下面我就说下我的理解。一个微服务最小开发团队： 一方面明确开发基础环境。既然微服务了。那么你的应用已经不是一个简朴的服务可以满足需求或者你设想中的业务是需要一个服务平台才干解决的。那么最小配置将需要以下岗位。 项目经理：他会负责产品开发进度把控等等。优秀的项目经理决定你团队的战斗力。 产品经理：一个优秀的产品经理可以快速

4、把你的想法或者用户的需要精确形成各种需求，他是不可或缺的。 架构师： 一个精通各种设计理论，有丰富一线开发经验并且了解微服务的架构师他将是整个团队的核心。决定你整个产品的质量。 核心高级工程师： 他将会负责整个微服务开发门槛最高的API Gateway服务的人选。他的好坏直接决定你的产品性能。 高级工程师： 他是带领开发小组进行具体开发的人选。他决定了代码质量和单个单体应用的性能。 初中级工程师： 他们将是大多数具体功能开发者。在高级工程师的指导下开发出符合规定的代码，同时也是公司的后备人才，人才储备。微服务的架构是什么？ 我先展示一个最粗粒度的微服务架构，然后我们在一起一步一步完善它。为什么

5、采用API Gateway？ 相应用来说，不管你怎么变化技术。实际解决的业务可以抽象成一句话，客户端请求服务返回数据并向客户展示。客户端与服务端的通信我们常见的有两种方式。1. 客户端直接跟服务端通信。2. 客户端通过API Gateway 跟服务端通信。 理论上说，一个客户端可以直接给多个微服务中的任何一个发起请求。每一个微服务都会有一个对外服务端。这个URL也许会映射到微服务的负载均衡上，它再转发请求到具体节点上。为了搜索产品细节，移动端需要向上述微服务逐个发请求。不幸的是，这个方案有很多困难和限制。其中一个问题是客户端的需求量与每个微服务暴露的细粒度API数量的不匹配。如图中，客户端需要

6、7次单独请求。在更复杂的场景中，也许会需要更多次请求。例如，亚马逊的产品最终页要请求数百个微服务。虽然一个客户端可以通过LAN发起很多个请求，但是在公网上这样会很没有效率，这个问题在移动互联网上尤为突出。这个方案同时会导致客户端代码非常复杂。另一个存在的问题是客户端直接请求微服务的协议也许并不是web和谐型。一个服务也许是用Thrift的RPC协议，而另一个服务也许是用AMQP消息协议。它们都不是浏览或防火墙和谐的，并且最佳是内部使用。应用应当在防火墙外采用类似HTTP或者WEBSocket协议。这个方案的另一个缺陷是它很难重构微服务。随着时间的推移，我们也许需要改变系统微服务目前的切分方案。

7、例如，我们也许需要将两个服务合并或者将一个服务拆分为多个。但是，假如客户端直接与微服务交互，那么这种重构就很难实行。由于上述三种问题的因素，客户端直接与服务器端通信的方式很少在实际中使用。通常来说，一个更好的解决办法是采用API Gateway的方式。API Gateway是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade模式很像。API Gateway封装内部系统的架构，并且提供API给各个客户端。它还也许有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应解决等。API Gateway负责请求转发、合成和协议转换。所有来自客户端的请求都要先通过A

8、PI Gateway，然后路由这些请求到相应的微服务。API Gateway将经常通过调用多个微服务来解决一个请求以及聚合多个服务的结果。它可以在web协议与内部使用的非Web和谐型协议间进行转换，如HTTP协议、WebSocket协议。API Gateway可以提供应客户端一个定制化的API。它暴露一个粗粒度API给移动客户端。以产品最终页这个使用场景为例。API Gateway提供一个服务提供点（/productdetails?productid=xxx）使得移动客户端可以在一个请求中检索到产品最终页的所有数据。API Gateway通过调用多个服务来解决这一个请求并返回结果，涉及产品信息

9、、推荐、评论等。一个很好的API Gateway例子是Netfix API Gateway。Netflix流服务提供数百个不同的微服务，涉及电视、机顶盒、智能手机、游戏系统、平板电脑等。起初，Netflix视图提供一个合用全场景的API。但是，他们发现这种形式不好用，由于涉及到各式各样的设备以及它们独特的需求。现在，他们采用一个API Gateway来提供容错性高的API，针对不同类型设备有相应代码。事实上，一个适配器解决一个请求平均要调用6到8个后端服务。Netflix API Gateway天天解决数十亿的请求。API Gateway的优点和缺陷如你所料，采用API Gateway也是优缺

10、陷并存的。API Gateway的一个最大好处是封装应用内部结构。相比起来调用指定的服务，客户端直接跟gatway交互更简朴点。API Gateway提供应每一个客户端一个特定API，这样减少了客户端与服务器端的通信次数，也简化了客户端代码。API Gateway也有一些缺陷。它是一个高可用的组件，必须要开发、部署和管理。尚有一个问题，它也许成为开发的一个瓶颈。开发者必须更新API Gateway来提供新服务提供点来支持新暴露的微服务。更新API Gateway时必须越轻量级越好。否则，开发者将由于更新Gateway而排队列。但是，除了这些缺陷，对于大部分的应用，采用API Gateway的方

11、式都是有效的。实现一个API Gateway既然我们已经知道了采用API Gateway的动机和优缺陷，下面来看在设计它时需要考虑哪些事情。性能和可扩展性只有少数公司需要解决像Netflix那样的规模，天天需要解决数十亿的请求。但是，对于大多数应用，API Gateway的性能和可扩展性也是非常重要的。因此，创建一个支持同步、非阻塞I/O的API Gateway是故意义的。已有不同的技术可以用来实现一个可扩展的API Gateway。在JVM上，采用基于NIO技术的框架，如Netty，Vertx，Spring Reactor或者JBoss Undertow。Node.js是一个非JVM的流行平

12、台，它是一个在Chrome的JavaScript引擎基础上建立的平台。一个可选的方案是NGINX Plus。NGINX Plus提供一个成熟的、可扩展的、高性能web服务器和反向代理，它们均容易部署、配置和二次开发。NGINX Plus可以管理授权、权限控制、负载均衡、缓存并提供应用健康检查和监控。采用反映性编程模型对于有些请求，API Gateway可以通过直接路由请求到相应的后端服务上的方式来解决。对于此外一些请求，它需要调用多个后端服务并合并结果来解决。对于一些请求，例如产品最终页面请求，发给后端服务的请求是互相独立的。为了最小化响应时间，API Gateway应当并发的解决互相独立的请

13、求。但是，有时候请求之间是有依赖的。API Gateway也许需要先通过授权服务来验证请求，然后在路由到后端服务。类似的，为了获得客户的产品愿望清单，需要先获取该用户的资料，然后返回清单上产品的信息。这样的一个API 组件是Netflix Video Grid。运用传统的同步回调方法来实现API合并的代码会使得你进入回调函数的恶梦中。这种代码将非常难度且难以维护。一个优雅的解决方案是采用反映性编程模式来实现。类似的反映抽象实现有Scala的Future，Java8的CompletableFuture和JavaScript的Promise。基于微软.Net平台的有Reactive Extensi

14、ons(Rx)。Netflix为JVM环境创建了RxJava来使用他们的API Gateway。同样地，JavaScript平台有RxJS，可以在浏览器和Node.js平台上运营。采用反映编程方法可以帮助快速实现一个高效的API Gateway代码。服务调用一个基于微服务的应用是一个分布式系统，并且必须采用线程间通信的机制。有两种线程间通信的方法。一种是采用异步机制，基于消息的方法。这类的实现方法有JMS和AMQP。此外的，例如Zeromq属于服务间直接通信。尚有一种线程间通信采用同步机制，例如Thrift和HTTP。事实上一个系统会同时采用同步和异步两种机制。由于它的实现方式有很多种，因此A

15、PI Gateway就需要支持多种通信方式。服务发现API Gateway需要知道每一个微服务的IP和端口。在传统应用中，你也许会硬编码这些地址，但是在现在云基础的微服务应用中，这将是个简朴的问题。基础服务通常会采用静态地址，可以采用操作系统环境变量来指定。但是，探测应用服务的地址就没那么容易了。应用服务通常动态分派地址和端口。同样的，由于扩展或者升级，服务的实例也会动态的改变。因此，API Gateway需要采用系统的服务发现机制，要么采用服务端发现，要么是客户端发现。后续的一篇文章将会更具体的介绍这部分。假如采用客户端发现服务，API Gateway必须要去查询服务注册处，也就是微服务实例

16、地址的数据库。解决部分失败在实现API Gateway过程中，此外一个需要考虑的问题就是部分失败。这个问题发生在分布式系统中当一个服务调用此外一个服务超时或者不可用的情况。API Gateway不应当被阻断并处在无限期等待下游服务的状态。但是，如何解决这种失败依赖于特定的场景和具体服务。例如，假如是在产品详情页的推荐服务模块无响应，那么API Gateway应当返回剩下的其他信息给用户，由于这些信息也是有用的。推荐部分可以返回空，也可以返回固定的顶部10个给用户。但是，假如是产品信息服务无响应，那么API Gateway就应当给客户端返回一个错误。在缓存有效的时候，API Gateway应当可

17、以返回缓存。例如，由于产品价格变化并不频繁，API Gateway在价格服务不可用时应当返回缓存中的数值。这类数据可以由API Gateway自身来缓存，也可以由Redis或Memcached这类外部缓存实现。通过返回缓存数据或者默认数据，API Gateway来保证系统错误不影响到用户体验。Netflix Hystrix对于实现远程服务调用代码来说是一个非常好用的库。Hystrix记录那些超过预设定的极限值的调用。它实现了circuit break模式，使得可以将客户端从无响应服务的无尽等待中停止。假如一个服务的错误率超过预设值，Hystrix将中断服务，并且在一段时间内所有请求立刻失效。Hystrix可认为请求失败定义一个fallback操作，例如读取缓存或者返回默认值。假如你在用JVM，就应当考虑使用Hystrix。假如你采用的非JVM环境，那么应当考虑采用类似功能的库。