微服务之间的调用方法哪个更好
发布时间：2023-02-16 09:26:13 所属栏目：云计算 来源：互联网
导读：在微服务架构中，需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。 服务调用有两种方式，一种是RPC方式，另一种是事件驱动（Event-driven）方式，也就是发消息方式。 先说读数据，假设要创建一个Order，在这个过
|
在微服务架构中，需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。 服务调用有两种方式，一种是RPC方式，另一种是事件驱动（Event-driven）方式，也就是发消息方式。 先说读数据，假设要创建一个“Order”，在这个过程中需要读取“Customer”的数据和“Product”数据。 如果用事件通知的方式就只能在“Order Service”本地也创建只读“Customer”和“Product”表，并把数据用消息的方式同步过来。 再说写数据，如果在创建一个“Order”时需要创建一个新的“Customer”或要修改“Customer”的信息，那么可以在界面上跳转到用户创建页面，然后在“Customer Service”创建用户之后再发”用户已创建“的消息，“Order Service”接到消息，更新本地“Customer”表。 这并不是一个很好的使用事件驱动的例子，因为事件驱动的优点就是不同的程序之间可以独立运行，没有绑定关系。但现在“Order Service”需要等待“Customer Service”创建完了之后才能继续运行，来完成整个创建“Order”的工作。主要是因为“Order”和“Customer”本身从逻辑上来讲就是紧耦合关系，没有“Customer”你是不能创建“Order”的。 这是一种具有颠覆性质的的设计，它把系统中所有的数据都以事件（Event）的方式记录下来，它的持久存储叫Event Store， 一般是建立在数据库或消息队列（例如Kafka）基础之上，并提供了对事件进行操作的接口，例如事件的读写和查询。事件溯源是由领域驱动设计(Domain-Driven Design)提出来的。 有界上下文的一个关键是如何处理共享成员， 在图中是“Customer”和“Product”。在不同的有界上下文中，共享成员的含义、用法以及他们的对象属性都会有些不同，DDD建议这些共享成员在各自的有界上下文中都分别建自己的类（包括数据库表），而不是共享。可以通过数据同步的手段来保持数据的一致性。 另一种是其他微服务也关心的，是颗粒度比较粗的，这种事件会放到另外一个或几个stream中，被多个微服务使用，是用来做服务之间集成的。这样做的好处是限制了事件的作用范围，减少了不相关事件对程序的干扰。详见"Domain Events vs. Event Sourcing"。 事件溯源出现已经很长时间了，虽然热度一直在上升（尤其是这两年），但总的来说非常缓慢，谈论的人不少，但生产环境使用的不多。究其原因就是应为它对现在的体系结构颠覆太大，需要更改数据存储结构和程序的工作方式，还是有一定风险的。 另外，微服务已经形成了一整套体系，从程序部署，服务发现与注册，到监控，服务韧性（Service Resilience），它们基本上都是针对RPC的，虽然也支持消息，但成熟度就差多了，因此有不少工作还是要自己来做。 有意思的是Kafka一直在推动它作为事件驱动的工具，也取得了很大的成功，但它却没有得到事件溯源圈内的认可。 RPC的方式就是远程函数调用，像RESTFul，gRPC, DUBBO 都是这种方式。它一般是同步的，可以马上得到结果。在实际中，大多数应用都要求立刻得到结果，这时同步方式更有优势，代码也更简单。 1、服务网关（API Gateway） 熟悉微服务的人可能都知道服务网关（API Gateway）。当UI需要调用很多微服务时，它需要了解每个服务的接口，这个工作量很大。 有了API Gateway之后，一旦服务接口修改，你可能只需要修改API Gateway， 而不必修改每个调用这个函数的客户端，这样就减少了程序的耦合性。 2、服务调用 可以借鉴API Gateway的思路来减少RPC调用的耦合度，例如把多个微服务组织起来形成一个完整功能的服务组合，并对外提供统一的服务接口。这种想法跟上面的API Gateway有些相似，都是把服务集中起来提供粗颗粒（Coarse Granular）服务，而不是细颗粒的服务（Fine Granular）。 但这样建立的服务组合可能只适合一个程序使用，没有多少共享价值。因此如果有合适的场景就采用，否侧也不必强求。虽然我们不能降低RPC服务之间的耦合度，却可以减少这种紧耦合带来的影响。 总的来说微服务的数量不要太多，不然会有比较重的运维负担。有一点需要明确的是微服务的流行不是因为技术上的创新，而是为了满足管理上的需要。单体程序大了之后，各个模块的部署时间要求不同，对服务器的优化要求也不同，而且团队人数众多，很难协调管理。 把程序拆分成微服务之后，每个团队负责几个服务，就容易管理了，而且每个团队也可以按照自己的节奏进行创新，但它给运维带来了巨大的麻烦。所以在微服务刚出来时，我一直觉得它是一个退步，弊大于利。但由于管理上的问题没有其他解决方案，只有硬着头皮上了。 值得庆幸的是微服务带来的麻烦都是可解的。直到后来，微服务建立了全套的自动化体系，从程序集成到部署，从全链路跟踪到日志，以及服务检测，服务发现和注册，这样才把微服务的工作量降了下来。 虽然微服务在技术上一无是处，但它的流行还是大大推动了容器技术，服务网格（Service Mesh）和全链路跟踪等新技术的发展。不过它本身在技术上还是没有发现任何优势。 直到有一天，我意识到单体程序其实性能调试是很困难的（很难分离出瓶颈点），而微服务配置了全链路跟踪之后，能很快找到症结所在。看来微服务从技术来讲也不全是缺点，总算也有好的地方。但微服务的颗粒度不宜过细，否则工作量还是太大。 一般规模的公司十几个或几十个微服务都是可以承受的，但如果有几百个甚至上千个，那么绝不是一般公司可以管理的。尽管现有的工具已经很齐全了，而且与微服务有关的整个流程也已经基本上全部自动化了，但它还是会增加很多工作。 Martin Fowler几年以前建议先从单体程序开始（详见 MonolithFirst），然后再逐步把功能拆分出去，变成一个个的微服务。但是后来有人反对这个建议，他也有些松口了。 如果单体程序不是太大，这是个好主意。可以用数据额库表的数量来衡量程序的大小，我见过大的单体程序有几百张表，这就太多了，很难管理。正常情况下，一个微服务可以有两、三张表到五、六张表，一般不超过十张表。但如果要减少微服务数量的话，可以把这个标准放宽到不要超过二十张表。 用这个做为大致的指标来创建微程序，如果使用一段时间之后还是觉得太大了，那么再逐渐拆分。当然，按照这个标准建立的服务更像是服务组合，而不是单个的微服务。不过它会为你减少工作量。只要不影响业务部门的创新进度，这是一个不错的方案。 到底应不应该选择微服务呢？如果单体程序已经没法管理了，那么你别无选择。如果没有管理上的问题，那么微服务带给你的只有问题和麻烦。其实，一般公司都没有太多选择，只能采用微服务，不过你可以选择建立比较少的微服务。如果还是没法决定，有一个折中的方案，“内部微服务设计”。 虽然它们的数据库中的数据应该大致相同，但DDD建议每一个有界上下文中都建一个新表，它们之间再进行数据同步。 这个所谓的“内部微服务设计”其实就是DDD，但当时还没有微服务，因此外表看起来是单体程序，但内部已经是微服务的设计了。 它的书在2003就出版了，当时就很有名。但它更偏重于业务逻辑的设计，践行起来也比较困难，因此大家谈论得很多，真正用的较少。 直到十年之后，微服务出来之后，人们发现它其实内部就是微服务，而且微服务的设计需要用它的思想来指导，于是就又重新焕发了青春，而且这次更猛，已经到了每个谈论微服务的人都不得不谈论DDD的地步。不过一本软件书籍，在十年之后还能指导新技术的设计，非常令人钦佩。 当然你也要应对随之而来的各种运维麻烦。内部微服务设计是一个折中的方案，如果你想试水微服务，但又不愿意冒太大风险时，这是一个不错的选择。 （编辑：莱芜站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
