微服务基础
微服务基础篇
- 1: service consumer -> Proxy Server ->Load Balance -> Service Discovery -> Target Service
2: Broser curl Other -> Zuul -> Ribbon -> Euraka -> Restful API
zuul: 是边缘服务,用来提供动态路由,监控,授权,安全,调度等功能,将权限控制等一些业务逻辑抽离出来,单独放到Zuul里,使得服务组件更简单,具有更好的复用性.
Zuul还负责将请求路由到服务上,起到了前台接待人员的作用,负责访客接待,当然也可以不使用zuul,
这时请求直接与后台的服务交互,但是这样破坏了接口原则,相当于不要前台人员直接去公司里面找人zuul是反向代理工具,类似的还有Nginx,
区别:
正向代理 代理的是客户端,反向代理代理的是服务端
正向代理: 服务端不知道客户端是谁.
反向代理: 客户端不知道服务端是谁.Ribbon 维护了一个服务列表,如果实例注销,ribbon能够自行将其剔除,但是如果该服务实例重新启动或者增加实例,需要手工调用Ribbon的接口吧服务加进Ribbon的服务列表.
这个工作还是交给euraka好了,所以一般二者结合使用.
客户端负载均衡: 具体来说是通过采取某种策略为客户端选择一个服务端,从而能够减少对服务端的压力,达到均衡负载的效果Feign: 是一个组件也是一个webservice客户端,用户服务之间调用.
微服务之间的通信有同步和异步: 同步的方式有: Rest,SOAP,RPC ,其中 Rest是面向资源的,SAOP的面向方法的,RPC是面向接口的.
Rest的主要特点: 每个资源都有一个ID,链接资源在一起,使用标准方法,资源多重描述,无状态通信, 优势: 易开发已维护,使用RPC的话,需要调用接口方法,代码上有渗透.
AXIS,CXF都会根据WSDL文件生成客户端代码,调用时代码耦合很多第三方代码Kafka: 来自LinkedIn之后成为Apache的一部分,Kafka本身是一个基于分布式系统,具有快速,可扩展,高性能,低耦合,高可靠性,数据不丢失等优点,
相比于传统消息系统有:(1)基于分布式(2)可同时为发布和订阅提供高吞吐量(3)支持多订阅者,当失败时能自动平衡消费者(4)将消息持久化到磁盘,因此可用于批量消费,如ETL以及实时应用等
系统架构:Broker:Kafka集群包含一个或多个服务器,这些服务器被称为Broker
Topic: 集群上有很多Topic,每个topic代表一类消息,所有发布到集群上的消息都会进入到属于自己的那个topic中,等待被处理
Partition:在物理存储上,每个topic包含一个或多个patition,创建topic时刻指定partition的数量,每个partition对应于一个文件夹,该文件夹下存储该partition的数据和索引文件.
Producer: 负责发布消息到Kafaka broker
Consumer: 消息消费者,负责从kafka broker读取消息进行处理.
Consumer Group: 每个消费者都属于一个特定的Consumer Group,没有就是默认组.
最后更新:2017-10-23 12:33:35