service mesh（在微服务架构中，我们还需要ESB吗）

本文目录

• 在微服务架构中，我们还需要ESB吗
• 说说你所在互联网公司微服务项目都用哪些技术
• spring cloud和dubbo哪个会被淘汰
• 如何实现一个分布式RPC框架

在微服务架构中，我们还需要ESB吗

微服务架构可以理解为一种架构风格，将一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
对于微服务架构来说，他们更专注于对于系统应用和业务的解耦，可以达到快速开发，快速迭代的目的，而ESB则是专注将各个系统之间服务集成和转换，强调的是系统间的强强关联，看上去和微服务的理念是相冲突的，在同一环境下只能存在一个。但实际情况并不是这样的。
1. 微服务架构虽然优势很多，但是还处在一个发展过程，虽然目前很多的产品都在慢慢转型，但是还是需要时间，对于相对复杂的业务，并不能完全实现，而ESB能够做的，更多的是协助业务系统进行服务的转换，服务的开发，弥补业务系统当前环境下的不足，满足业务场景的快速对接和实现，相比理想化的结果，利用现有资源，更能进行快速的反应和实现。
2. 虽然微服务架构能够实现快速的开发和迭代，但是随着业务的复杂，系统的增多，对接难度也会变大，小改动可能变动一方改动，大改动双方都要改动，成本和周期都是需要衡量的，而ESB虽然前期投入很高，但是从长远来看，成本和开发周期都是最低的，对于客户来说，也是更容易接受的。
3. 让一个企业所有的业务系统都能支持微服务的开发是不可能的，相对于版本较低的产品，可能都不支持开发，有可能服务都没有，这种情况下，更多的是做好IT资产的复用和兼容，微服务和ESB相结合的方式，只有这样，才能获取更多的市场，满足更多业务场景的快速实现。

数通畅联专注于企业IT架构、SOA综合集成、数据治理分析领域，感谢您的阅读与关注

说说你所在互联网公司微服务项目都用哪些技术

很高兴回答您的问题。

目前我们在做的一个项目全面使用微服务架构。也确实从中获得了极大的便利。

首先，确定模块的划分，就我们的项目而言，分为：

1. 前端模块，对外提供REST API接口

2.负责具体逻辑处理的模块，前端模块和此模块通过GRPC通信

3.异步处理模块，有些任务耗时较长，模块二会发送一个消息到kafka，此模块从kafka获取消息，进行异步处理

系统部署在kubernetes之上，所有模块编译成docker image，上传到自己私有的image repo。

每个模块都有多个副本，以实现负载均衡。模块之间的通信，通过kubernetes cluster service实现。

kubernetes ingress负责对外提供访问接口以及ssl的处理。

外层再使用load balancer，以实现在多个cluster之间负载均衡以及容错。多个cluster部署在不同的region，以避免区域出现问题使服务不可用。

cluster里面还使用了istio，以便利用service mesh。

此外监控也是必不可少的，我们使用prometheus来监控各项指标，alertmanager实现报警。

ELK实现对日志的记录与查询，jaeger实现模块间同一个request的trace。

目前稳定运行，效果非常不错。

希望我的回答对您能有帮助。

spring cloud和dubbo哪个会被淘汰

事实上，很多系统根本就没必要用什么所谓微服务。目前过度设计已经泛滥，明明是一个用户数量有限，功能并不复杂的系统，也要套用所谓的微服务架构，或者要大搞所谓中台，既浪费时间，又浪费金钱，最后系统运维还比较复杂，需要持续投入运维。

以服务调用的方式，固然可以有更好的复用性，也可以解耦复杂系统。但实际上，我认为微服务也仅仅是组件化的一种实现方式。对于组件化，广义的讲，有多种实现方式：

第一种，最原始的方式就是以静态函数库或者包的形式存在。这种形式优点是开发方式简单，调用效率高，数据以参数方式进行传递，但耦合度也高，底层组件函数一旦发生变化，则需要重新编译整个工程。通常对于不经常发生变化的基础函数库，可以用这种形式进行开发，形成所谓的公共函数库，供大家使用。

第二种，称之为动态函数库，在windows环境下以dll形式存在，linux环境下以so形式存在。动态函数库相对于静态函数库，优势在于可以在运行时动态加载，可以在不用重新启动整个应用的情况下进行更新。缺点是动态函数不能共享原应用程序的存储空间，导致动态函数调用有时需要传递大量参数，导致一些不便。动态函数库也具有一定耦合度，函数名和参数必须严格按照约定调用，否则会报错。在早期单体架构下，动态函数库还是有大量使用的。

第三种，就是目前所谓的微服务架构了。微服务事实上也是可以看作是一种函数调用方式，提供基于RPC和restful远程调用方式。调用时需要传递调用的服务名称及数据报文。这种方式耦合度自然是比较低一些的，但是调用效率肯定低于函数调用方式，主要是数据传输和报文解析方面消耗的时间。此外还需要考虑通讯流量控制，超时机制，服务寻址，服务可用性等方面的问题。因而降低耦合度，事实上是以增加了系统的整体复杂度和降低调用效率为代价的。个人认为不应该过度解耦，或者仅仅强调可复用性。要知道，任何事情都是有代价的，必须要充分评估这种代价是否值得。

第四种，就更进一步，即以独立的系统存在，该系统具有独立性和完备性，可以不过于依赖其他外部系统独立运行，对外部以服务或api的形式进行交互。例如，单点登录系统，信贷系统，核心系统等。

因而，在系统架构设计和建设过程中，必须认真进行评估，不应该过分侧重于某一方面特性的实现，否则就是过犹不及，最后导致整体出现问题。

个人认为，目前大部分所谓基于微服务的中台系统就是陷入了过于强调解耦的误区，导致过度的解耦设计，而忽略了由此带来的弊端，最后陷入了泥潭。

如何实现一个分布式RPC框架

1.定义:

明确下RPC是什么?PRC全称是Remote Procedure Call,是进程间的一种通信方式。

2.解决的问题

进程间调用就像本地调用函数一样简单，而业务层不需要去关心通信的细。

3.组成

在Nelson的论文Implementing Remote Procedurr Calls有论述，见图1

User 调用方

User-Stub 消息拼装，编解码

RPCRuntime 发送，接受消息

Service-Stub 消息拼装，编解码

Server 服务方

4.核心实现

从图中可以看出我们需要实现Stub和RPCRuntime的功能。

Stub:主要功能是消息格式怎么定义和编解码。

消息格式:一般需要设计消息头和消息体，当然越简洁越好，提高传输效率

编解码:二进制最高效,可以使用Protocol Buffers,Thrift。当然也可以使用可读性比较好的JSON,XML。

RPCRuntime主要负责通信，这里涉及到选择什么IO模型，BIO,NIO还是AIO,可以使用netty来实现NIO功能。

5.开源实现

了解开源实现，更能促进自研的成熟稳定。当然看需求是否需要自研，一般开源就可以满足需求了。

比较好的开源实现有Dubbo,brpc,grpc,Thrift,Hessian等

6.小结

虽然RPC说起来只是进程间的通信，但是RPC服务怎么注册，发现，路由这些都还是需要考虑的。再者毕竟是网络传输，就有可能出现延迟，丢包的情况，容错性也需要多考虑考虑。这里再把RPC调用描述的全一点，见图2。图中的clinet,sever只和agent交互，agent就包含了Stub和RPCRuntime的功能，一般这里的agent实现为一个jar包，和应用程序部署在一起。

现在Service Mesh也越来越成熟了，Service Mesh把agent独立为一个进程部署（必须和业务同一机器），这样降低了耦合性，同时业务和平台独立，开发迭代速度也更快。提到Service Mesh的开源实现必提Istio。图3是Istio官网的架构图。

希望回答对你有帮助，记得点个赞哦，谢谢。也可以关注我，后面会分享一些架构的知识。