存档

‘应用架构’ 分类的存档

API网关apisix试用

2020年5月17日 没有评论 244 次浏览

API网关有什么作用? 路由:根据上下文或消息内容将请求发送到不同的目的地(可能需要借助Service... [阅读更多]

服务发现和负载均衡

2020年5月1日 没有评论 378 次浏览

网络上已经有很多介绍这方面的文章,可以查看参考或自行Google关键字”服务发现和负载均衡”,但我这里仍然做个Mark,毕竟这是微服务架构中极其重要的内容。 总结来看,客户端如何发现服务端只有两种方式,要么直接把服务端的地址告诉客户端,要么把一个第三方(也就是代理)的地方告诉客户端,然后让客户端去询问这个第三方其所需要的服务端地址在哪里。 直接告诉的方式不用讨论,因为很简单,而利用代理的方式稍显复杂,根据代理所处的不同部署位置而区分出不同的模式。 最经典的模式就是传统集中代理模式(Proxy... [阅读更多]

Go rpcx试用

2020年4月25日 没有评论 380 次浏览

前段时间看了下分布式RPC框架brpc,这两天在找分布式服务框架,也就是除了RPC功能外,期望还能有服务发现和服务治理的功能,经典的开源框架有dubbo,之前据说这货在阿里的团队都解散了(15年),后来又据说开始维护了(17年底。具体见这里:https://www.zhihu.com/question/30884501,https://github.com/apache/dubbo),但我想找个Go语言的类似框架,Google了下,发现有个rpcx(还有些其他框架,比如go-micro等),看上去挺不错,而且是国人开发的,主要贡献者在微博工作(见参考)。 老套路,还是先试用下rpcx。 一,测试环境 $... [阅读更多]

braft试用

2020年3月22日 没有评论 679 次浏览

raft是一个分布式一致性复制协议算法,其基本功能就是可以实现在多个进程之间对某个(某些)值达成强一致性,前面文章介绍的Zookeeper和Etcd就利用了raft(以及类似协议zab、paxos等)。而braft是百度实现的基于brpc的raft协议工业级C++实现,抛开各种理论说明不谈,只需知道利用braft可以帮助解决分布式系统中的数据一致性以及延伸问题,比如: 1,分布式锁:锁信息的一致性 2,分布式存储:存储数据的一致性 3,主备高可用:元数据的一致性 等等。 除了braft,自然还有很多其他的raft的实现,比如SOFAJRaft等,具体见备注。下面就主要试用一下braft。 一,测试环境 $... [阅读更多]

配置中心

2020年3月21日 没有评论 510 次浏览

所谓集群,就是将部署在多个服务器上的相同应用集合在一起做同一件事情。因此,集群首先要解决的问题就是如何将多个服务器主机上的应用进行统一的管理,达到从外面看来就像是只有一个服务器主机在跑应用一样,这就要求集群系统必须具备全局信息的管理能力。比如应用程序的运行一般总是依赖一些配置信息,不可能让用户对集群里的每台主机去做单独的配置,而是由集群系统自动实现配置信息的全局同步,直接点说就是需要一个配置中心进行统一管理。 配置中心的主要作用是维护一致性信息,实现集群各主机的协调管理,因此其不仅仅只是用来存储共享配置,还可以用来存储其他各种公共的信息,比如服务信息,因此就可以实现服务注册和服务发现;比如锁信息,从而提供分布式锁机制等等。当前主流配置中心一般都包括配置管理、集群成员管理、命名服务、任务分配、心跳检测、分布式锁等功能。 当前社区可选的优秀开源有Zookeeper和Etcd,下面简单看一下。 1,Zookeeper 官网:http://zookeeper.apache.org/ Zookeeper起源于Hadoop,后来进化为Apache的顶级项目。现在已经被广泛使用在Apache的项目中,例如Hadoop,Kafka,Solr等等。 Zookeeper是Java写的,因此依赖Java环境,客户端官方语音支持C、Java,但GitHub上可以搜索到其他语言的客户端实现。 2,Etcd 官网:https://etcd.io/ Etcd是用go语言开发的,Etcd官方提供有Go语言和Java语言的SDK。 Etcd出现的时间并不长,但前景貌似非常好,在Kubernetes的kube... [阅读更多]

消息队列

2020年3月15日 没有评论 843 次浏览

如果两/多个系统之间要进行同步协作,RPC(远程过程调用)可能是首选方案。但如果是异步协作,那么MQ(消息队列)也许更有吸引力,因为相比RPC提供的异步调用功能,MQ具备更多的优秀特性。 MQ与RPC的不同点在于可以存储消息(以及Broker,即消息转发器),因此MQ除了可以对消息相关的两/多方进行解耦之外,还有如下特点: 1,异步:MQ具备天然的异步特性,消息发送方和接收方都只需关注消息本身即可,无需过多考虑对端的情况。 2,可靠投递:消息存于MQ里,例如接收方可以反复读取,直到成功处理为止,并且通过ACK机制进行消费确认。 3,多播/广播:可以有多个接收方读取同一个消息,还可以进行消息的订阅/发布。 4,流量削峰:MQ相当于一个消息的蓄水池,处理不完的消息暂存在MQ里,不会冲爆消息接收方,也就是类似于流量控制的作用。 5,事务处理:通过记录补偿,本地事务,本地落地,补偿发送等多种手段实现事务化处理。 6,可靠性:将消息持久化,实现宕机重启后,消息可以从持久化存储恢复,消息不丢失。 7,高可用性:支持集群。 以上这些特点可以给系统带来各种好处,比如解耦、性能、吞吐、健壮性、最终一致性等方面都得到提升。 社区有很多优秀的MQ开源,目前主流使用的有: 1,Kafka http://kafka.apache.org/ Apache社区开源的MQ产品,可用于系统间的数据流管道,实时数据处理,因此在大数据领域的实时计算以及日志采集被应用较多,依赖Zookeeper一起使用。使用Scala语言开发,社区活跃度和文档完备性都非常高,客户端语言支持C/C++、Python、Go、Erlang、.NET、Ruby、Node.js、PHP等。 2,RocketMQ http://rocketmq.apache.org/ Alibaba开发的MQ产品,目前已加入到Apache下,主要用于非日志的可靠消息传输。例如:订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发等。使用Java语言开发,客户端语言目前支持Java、C/C++、Python、Go等。 3,Redis5.0+ https://redis.io/ Redis5.0新增了一个数据结构Stream,可以用来实现典型的消息队列。Redis作者坦言Stream狠狠的借鉴了Kafka的设计,并且Redis作者在很久之前就开发过一个分布式消息队列Disque,由于有众多经验在前,那么这个消息队列Stream应该不至于很差。Redis比较常用,很多应届生或初学者都会学习Redis,其本身使用C语言开发,支持的客户端语言众多,安装部署使用都会更加简单。 总的来说,如果业务偏向于大数据或日志处理,可以选用Kafka。 如果业务偏向于电商类,可以考虑RocketMQ。 如果想要更加轻量级的MQ,特别是如果业务系统里已经有Redis的应用,那么不妨试试Redis5.0+里的Stream。 参考: 1,https://stackoverflow.com/questions/962436/what-are-the-disadvantages-of-rpc-with-respect-to-message-passing ... [阅读更多]

远程过程调用brpc试用

2020年3月14日 没有评论 577 次浏览

Rpc用得越来越多,因此想看一下当前开源界有哪些优秀的Rpc项目,从这里摘到了如下一段,像是对目前流行的Rpc项目做了一下大致介绍: grpc(google)https://github.com/grpc/grpc thrift(facebook):独特的序列化格式和IDL,支持很多编程语言。thrift的代码看似分层很清楚,client、server选择很多,但没有一个足够通用,每个server实现都只能解决很小一块场景,每个client都线程不安全。实际使用中非常麻烦。thrift的代码质量也比较差,接口和生成的代码都比较乱。https://github.com/apache/thrift dubbo(alibaba)https://github.com/alibaba/dubbo sofa-pbrpc(baidu):百度PS基于boost::asio和protobuf实现的RPC框架,这个库代码工整,接口清晰,支持同步和异步。sofa-pbrpc存在产品线自研框架的鲜明特点:不支持内部其他协议,对名字服务、负载均衡、服务认证、连接方式等多样化的需求的抽象不够一般化。https://github.com/baidu/sofa-pbrpc baidu-rpc(baidu)提供稳定的RPC框架;适用各类业务场景,提供优秀的延时,吞吐,并发度,具备优秀的多核扩展性;接口易懂,用户体验佳。有完备的调试和运维接口(HTTP)。https://github.com/brpc/brpc。 从上面评价来看,baidu-rpc算不错,因此下面尝试试用一下这个开源。 一,测试环境 $... [阅读更多]