《微服务学习笔记(一)》由会员分享，可在线阅读，更多相关《微服务学习笔记(一)（9页珍藏版）》请在金锄头文库上搜索。
1、微服务学习笔记(一) 什么是六边形架构 “六边形架构”是 ockburn大牛在提出的。该架构提供了一种将业务逻辑和具体输入输出技术分离的模式。为什么采用微服务 目前大多数开发一种应用,哪怕是类似Uber或者淘宝的应用。基本上都是已单体模式开发。虽然在应用自身架构上采用了模块化设计,但在本质上她还是一种单体应用。例如：如下图这样的单体应用不好吗？ 上图,是比较典型优秀的单体六边形架构。在诸多公司事实上由于多种因素单体应用架构还没有达到这个水平。因此会有如下几种方面问题1. 整体扩展性差,当应用越来越庞大后，进行新功能开发或者功能修改将会很困难。2.整体耦合度高，同样当应用庞大。解耦将是一种叫你头
2、疼的问题。3. 复杂度高，维护性差。当她足够庞大。新来的同事将会接手一种对她们看来是个怪物的东西,你会听到这些抱怨。这都是什么?你们究竟在想什么?. 性能低下，由于多种因素，重要是开发人员水平不一。你会发现整个应用越来越慢，你想找到因素变的越来越困难。代码有大量沉余，你每天都在纠结与否可以重建她（不是重构！)。为什么要采用微服务?不能直接采用比较高档的架构吗? 微服务事实上就是用多种单体应用的集合。用多种单体服务来解决某些复杂业务。在实际开发中,除了架构师，对单个开发人员来说她只是需要开发一种简朴的单体应用。开发门槛比较低，你觉得在成都，西安等这些二三线都市高水平的程序员是那么好找的吗？（二三
3、线小都市公司开不起工资,理解高档架构的高档程序员至少20，30K工资)。 综上，微服务将是解决二三线小都市，小公司问题的一种优秀方案。什么是微服务？微服务开发团队怎么组建？ 上文已经说了,微服务实际就是多种单体应用的集合。那么一种微服务开发团队需要那些人员呢？下面我就说下我的理解。一种微服务最小开发团队： 一方面明确开发基本环境。既然微服务了。那么你的应用已经不是一种简朴的服务可以满足需求或者你设想中的业务是需要一种服务平台才干解决的。那么最小配备将需要如下岗位。 项目经理：她会负责产品开发进度把控等等。优秀的项目经理决定你团队的战斗力。 产品经理：一种优秀的产品经理可以迅速把你的想法或者顾客
4、的需要精确形成多种需求,她是不可或缺的。 架构师: 一种精通多种设计理论，有丰富一线开发经验并且理解微服务的架构师她将是整个团队的核心。决定你整个产品的质量。 核心高档工程师:她将会负责整个微服务开发门槛最高的API Gteway服务的人选。她的好坏直接决定你的产品性能。 高档工程师:她是带领开发小组进行具体开发的人选。她决定了代码质量和单个单体应用的性能。 初中级工程师: 她们将是大多数具体功能开发者。在高档工程师的指引下开发出符合规定的代码，同步也是公司的后备人才,人才储藏。微服务的架构是什么? 我先展示一种最粗粒度的微服务架构，然后我们在一起一步一步完善它。为什么采用PIGaay？ 相应
5、用来说，不管你怎么变化技术。实际解决的业务可以抽象成一句话,客户端祈求服务返回数据并向客户展示。客户端与服务端的通信我们常用的有两种方式。1. 客户端直接跟服务端通信。2. 客户端通过APIGawy跟服务端通信。 理论上说，一种客户端可以直接给多种微服务中的任何一种发起祈求。每一种微服务都会有一种对外服务端。这个L也许会映射到微服务的负载均衡上，它再转发祈求到具体节点上。为了搜索产品细节,移动端需要向上述微服务逐个发祈求。不幸的是,这个方案有诸多困难和限制。其中一种问题是客户端的需求量与每个微服务暴露的细粒度AI数量的不匹配。如图中,客户端需要7次单独祈求。在更复杂的场景中，也许会需要更多次祈
6、求。例如,亚马逊的产品最后页要祈求数百个微服务。虽然一种客户端可以通过LA发起诸多种祈求，但是在公网上这样会很没有效率,这个问题在移动互联网上尤为突出。这个方案同步会导致客户端代码非常复杂。另一种存在的问题是客户端直接祈求微服务的合同也许并不是we和谐型。一种服务也许是用Tit的RPC合同,而另一种服务也许是用AMP消息合同。它们都不是浏览或防火墙和谐的，并且最佳是内部使用。应用应当在防火墙外采用类似HTP或者WEBSocket合同。这个方案的另一种缺陷是它很难重构微服务。随着时间的推移,我们也许需要变化系统微服务目前的切分方案。例如,我们也许需要将两个服务合并或者将一种服务拆分为多种。但是，
7、如果客户端直接与微服务交互，那么这种重构就很难实行。由于上述三种问题的因素，客户端直接与服务器端通信的方式很少在实际中使用。一般来说，一种更好的解决措施是采用API Gtewa的方式。API Gateway是一种服务器,也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Faca模式很像。 ateway封装内部系统的架构,并且提供PI给各个客户端。它还也许有其她功能,如授权、监控、负载均衡、缓存、祈求分片和管理、静态响应解决等。API Gatway负责祈求转发、合成和合同转换。所有来自客户端的祈求都要先通过AP Gatewa，然后路由这些祈求到相应的微服务。AI Gaewy将常常通过调用多种
8、微服务来解决一种祈求以及聚合多种服务的成果。它可以在wb合同与内部使用的非Wb和谐型合同间进行转换，如TT合同、Weoct合同。API Gateway可以提供应客户端一种定制化的API。它暴露一种粗粒度AP给移动客户端。以产品最后页这个使用场景为例。A Gwa提供一种服务提供点（/producet?poducidxxx)使得移动客户端可以在一种祈求中检索到产品最后页的所有数据。API Gaay通过调用多种服务来解决这一种祈求并返回成果,波及产品信息、推荐、评论等。一种较好的AP Gteway例子是NetfPI Gatewa。Netf流服务提供数百个不同的微服务，涉及电视、机顶盒、智能手机、游戏
9、系统、平板电脑等。起初,Netfli视图提供一种合用全场景的PI。但是,她们发现这种形式不好用，由于波及到各式各样的设备以及它们独特的需求。目前,她们采用一种A Gateway来提供容错性高的AP,针对不同类型设备有相应代码。事实上，一种适配器解决一种祈求平均要调用6到8个后端服务。Netflx AP tay每天解决数十亿的祈求。APatewa的长处和缺陷如你所料,采用A atwy也是优缺陷并存的。AI atewa的一种最大好处是封装应用内部构造。相比起来调用指定的服务，客户端直接跟gatway交互更简朴点。APIateway提供应每一种客户端一种特定AP,这样减少了客户端与服务器端的通信次数
10、，也简化了客户端代码。AI Gatwa也有某些缺陷。它是一种高可用的组件，必须要开发、部署和管理。尚有一种问题，它也许成为开发的一种瓶颈。开发者必须更新APItwa来提供新服务提供点来支持新暴露的微服务。更新AP Gatwy时必须越轻量级越好。否则，开发者将由于更新Gateway而排队列。但是,除了这些缺陷,对于大部分的应用,采用AP ateay的方式都是有效的。实现一种AI Gatewa既然我们已经懂得了采用AIGatewy的动机和优缺陷，下面来看在设计它时需要考虑哪些事情。性能和可扩展性只有少数公司需要解决像eflix那样的规模,每天需要解决数十亿的祈求。但是，对于大多数应用,PI Gat
11、wy的性能和可扩展性也是非常重要的。因此,创立一种支持同步、非阻塞I/的API Gateway是故意义的。已有不同的技术可以用来实现一种可扩展的AIateway。在M上，采用基于技术的框架，如Ntty，Vert,Srn Reator或者Bss Undertow。Noe.js是一种非JVM的流行平台,它是一种在Chrome的JvSript引擎基本上建立的平台。一种可选的方案是GINX lus。NGINXPlus提供一种成熟的、可扩展的、高性能web服务器和反向代理，它们均容易部署、配备和二次开发。NGINX Plu可以管理授权、权限控制、负载均衡、缓存并提供应用健康检查和监控。采用反映性编程模型
12、对于有些祈求,APIGatway可以通过直接路由祈求到相应的后端服务上的方式来解决。对于此外某些祈求，它需要调用多种后端服务并合并成果来解决。对于某些祈求，例如产品最后页面祈求,发给后端服务的祈求是互相独立的。为了最小化响应时间，I Gtway应当并发的解决互相独立的祈求。但是,有时候祈求之间是有依赖的。AI Gaewy也许需要先通过授权服务来验证祈求，然后在路由到后端服务。类似的，为了获得客户的产品愿望清单，需要先获取该顾客的资料，然后返回清单上产品的信息。这样的一种API 组件是NetfliVideo Grid。运用老式的同步回调措施来实现AI合并的代码会使得你进入回调函数的恶梦中。这种代
13、码将非常难度且难以维护。一种优雅的解决方案是采用反映性编程模式来实现。类似的反映抽象实既有Sala的uure，Java8的CompleabeFtur和JavaScipt的romise。基于微软.et平台的有eaive Extnon(Rx)。Netfli为JVM环境创立了Raa来使用她们的A Gateway。同样地,Javcript平台有RxJ，可以在浏览器和Nod.js平台上运营。采用反映编程措施可以协助迅速实现一种高效的API Gateway代码。服务调用一种基于微服务的应用是一种分布式系统，并且必须采用线程间通信的机制。有两种线程间通信的措施。一种是采用异步机制,基于消息的措施。此类的实现
14、措施有JMS和MQP。此外的,例如Zeromq属于服务间直接通信。尚有一种线程间通信采用同步机制，例如Thit和TTP。事实上一种系统会同步采用同步和异步两种机制。由于它的实现方式有诸多种,因此API Gaway就需要支持多种通信方式。服务发现API Gawy需要懂得每一种微服务的I和端口。在老式应用中，你也许会硬编码这些地址，但是在目前云基本的微服务应用中，这将是个简朴的问题。基本服务一般会采用静态地址,可以采用操作系统环境变量来指定。但是,探测应用服务的地址就没那么容易了。应用服务一般动态分派地址和端口。同样的，由于扩展或者升级,服务的实例也会动态的变化。因此,AP Gteway需要采用系
15、统的服务发现机制,要么采用服务端发现,要么是客户端发现。后续的一篇文章将会更具体的简介这部分。如果采用客户端发现服务,API Gateway必须要去查询服务注册处,也就是微服务实例地址的数据库。解决部分失败在实现API Gteway过程中,此外一种需要考虑的问题就是部分失败。这个问题发生在分布式系统中当一种服务调用此外一种服务超时或者不可用的状况。API Gateway不应当被阻断并处在无限期等待下游服务的状态。但是，如何解决这种失败依赖于特定的场景和具体服务。例如，如果是在产品详情页的推荐服务模块无响应，那么API Gatewy应当返回剩余的其她信息给顾客,由于这些信息也是有用的。推荐部分可以返回空,也可以返回固定的顶部1个给顾客。但是,如果是产品信息服务无响应,那么API Gtay就应当给客户端返回一种错误。在缓存有效的时候,PI ate应当可以返回缓存。例如,由于产品价格变化并不频繁，API Gaeway在价格服务不可用时应当返回缓存中的数值。此类数据可以由AP twa自身来缓存，也可以由Redis或Memcce此类外部缓存实现。通过返回缓存数据或者默认数据,AI ey来保证系统错误不影响到顾客体验。
