从0开始学习微服务(二)

微服务的一次远程调用
服务消费者与服务提供者之间的调用关系往往是通过注册中心实现的,那么服务消费者具体是怎么通过注册中心去调用服务提供者所提供的服务的呢
1.确定通信框架
我们称消费者为客户端,注册中心为服务端,客户端想要跟服务端进行通信首先要确定的就是通讯框架,现在常用的通讯框架有两种:
Http协议,通过应用层的http协议进行通信是常用的方式之一,通过传统的三次握手建立连接
Socket通信,socket通信相比http要复杂一些,但是传输效率更高,socket通信首先要确定的是一组套接字,比如tomcat的80端口,服务端首先bind端口,然后进行监听,客户端与套接字建立连接然后在服务端进行确认,当连接建立后可以send信息到服务端,然后服务端recieve到消息,这样进行数据传输

2.服务端如何处理请求
当一个请求到了服务端以后怎么处理也是一个很重要的方面,通常情况下有三种处理方式
Bio  所谓Bio即同步阻塞的方式,即每当有一个服务请求到达后服务器都会生成一个线程来处理请求,底层的实现是通过一个acceptor线程来接收客户端的请求,每当一个请求过来的时候都会在服务端新建立一个线程,这种方式的好处是实现逻辑简单,缺点是会启动大量的线程,导致服务端线程栈溢出,进而导致服务器崩溃,同时这种方式还是阻塞的,当服务端需要读取数据的时候客户端就会一直阻塞等待,所以服务的请求效率不仅跟客户端有关同时也跟服务端有关

NIO 同步非阻塞,NIO的处理方式不需要在服务器端生成多个线程,每当服务器生成请求之后都会讲请求放入buffer缓冲区域中,然后服务端会有一个select线程轮询所有请求,当有请求达到可读可写的状态时就会进行处理,从而可以实现非阻塞的处理客户端请求

3.数据如何传输
这个步骤是为了确定数据传输协议,可以是Http协议,也可以是dubbo协议,确定了传输协议之后就可以确定数据的传输格式,可以是json或者xml等

序言 自从Martin Fowler对微服务作出定义之后,微服务便火遍大江南北, 网上出现很多文章来描述它的好处,也有很多文章来说明它的弊端。这便 让很多小伙伴无所适从,微服务究竟是什么,要不要使用微服务架构,怎 么实施微服务架构?我一直认为,微服务架构只是新瓶装老酒,这老酒就 是模块化。如果在做系统设计时,已经把模块化做得很好,转型微服务只 是顺理成章的事。如果模块化都做不好,转型微服务只会带来灾难。 2014 年底,我们团队意识到 Docker 技术可以帮我们大幅度提高软 件产品的性能,降低硬件的投入,提高运维效率,便开始着手研发基于 Docker 的 PaaS 平台。随后,很快发现,PaaS 平台只是解决了软件生命周 期后半部分(运维)的问题,就思考能否通过 Docker 技术来提高开发团 队的效率。例如,降低团队成员流动带来的风险,提高多团队协作的效率, 找到组件或知识积累的方法,让同一个软件产品能够适应不同客户的定制 化需求,等等。从此,就与微服务结下了不解之缘。这些目标确定后,通 用的PaaS平台的研发目标也就变成了解决以上问题的微服务平台的研发, 以及后来的青柳云平台本身的微服务化的实践。 在做微服务架构技术选型的时候,我们以“无侵入”和“社区活跃” 为最主要的考量点,也只有这样,将来在升级为原子服务架构、量子服务 架构的时候,甚至是恢复成单体架构的时候,代价才是最小的。所以,在 3 InfoQ 中文站 为数不多的可选项中,我们拥抱了 Spring Cloud。最后的结果就是使用 基于 Docker 的微服务平台进行开发和运行运维支撑,使用 Spring Cloud 进行业务系统开发,两者相互独立,并可被独立替换。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值