分布式应用的各基本领域及开发技术概要.docx
- 文档编号:3199086
- 上传时间:2022-11-20
- 格式:DOCX
- 页数:9
- 大小:24.24KB
分布式应用的各基本领域及开发技术概要.docx
《分布式应用的各基本领域及开发技术概要.docx》由会员分享,可在线阅读,更多相关《分布式应用的各基本领域及开发技术概要.docx(9页珍藏版)》请在冰豆网上搜索。
分布式应用的各基本领域及开发技术概要
分布式应用的各基本领域及开发技术概要
分布式系统技术概要
现在互联网应用,尤其是大型互联网公司的应用已经发展为大规模或超大规模的分布式的,集群化的应用。
而中小规模的分布式应用也已广泛出现在各个领域。
未来,随着云计算向社会生活的方方面面去渗透,分布式应用将更加地普及。
所以,任何一个要从事服务器端应用开发的人员,都有具备对分布式应用的基本认识。
本文将简要介绍分布式应用的各基本领域的相关技术。
这些技术在一个分布式应用中都会有或多或少的设计,即便暂时没有涉及到,设计人员也要有所考虑,保证系统有进一步发展的空间。
1.集群管理
关键字:
ApacheZookeeper、Paxos算法、Etcd、Raft、ApacheCurator
在一个分布式系统中,存在着一些和系统运行,以及重要业务紧密相关的数据,如节点相关的数据、应用服务和数据服务相关的数据等,这些数据对集群的正常运行至关重要。
∙服务器节点相关数据:
服务器的地址、状态
∙服务相关数据:
服务的IP、端口、版本、协议、状态、主备节点信息
∙数据库相关数据:
路由规则、分库分表规则
这些重要的数据在分布式系统中存在着多份拷贝,以保证高可用性。
但这产生了另外一个问题,就是如何保证这些数据的一致性。
因为这些数据是如此重要,不一致的数据会产生严重甚至致命的错误。
在一个小规模的分布式系统中,因为可以用一两台服务器去做集群管理,所以数据的一致性容易实现。
但是对于一个大规模的分布式系统,一两台集群配置管理服务器无法支撑整个集群所带来的大量并发读写操作,所以要使用几台、十几台,甚至更多的服务器去支撑这些请求。
此时,就需要一个保持这些服务器中集群配置数据的一致性的方案了。
这众多方案中,Paxos算法算是最佳方案之一。
关于Paxos算法的内容,不在这里详述了。
简单描述就是集群中各节点相互以提议的方式通信(对一项数据的修改),提议中带有不断增加的ID号,节点永远同意当前ID号最大的提议,并拒绝其它提议。
当有半数以上节点同意一项提议之后,这个提议便被整个节点所接受并采纳。
1.1.ApacheZookeeper
Paxos算法的语言表述看上去不难,但是其中的技术难点并不少。
好在现在已经有了很多的解决方案,其中最为著名的便是ApacheZookeeper。
Zookeeper不仅可以用来存储配置数据,还可以用来实现集群Master选举、分布式锁等场景。
ApacheCurator是Zookeeper的客户端,可以简化对Zookeeper的使用,实现各式的场景。
Zookeeper是一个分布式的服务管理框架。
Zookeeper的典型的应用场景包括配置文件的管理、集群管理、分布式锁、Leader选举、队列管理等。
Zookeeper可工作在集群模式下,zoo.cfg中记录着集群中所有Zookeeper服务器的地址,每个服务器有自己唯一的ID。
同时,每个服务器在自己的dataDir目录下还要有一个myid文件,以标示自己的ID。
在Zookeeper中,数据以树状的结构存储,类似于LDAP数据库。
现在类似Zookeeper的项目还有使用go语言实现的Etcd。
1.2.参考:
∙Paxos算法
∙zookeeper节点数与watch的性能测试
∙etcd:
从应用场景到实现原理的全方位解读
∙etcdv2.1benchmarks
∙分布式配置服务etcdVS分布式协调服务zookeeper
2.远程调用
关键字:
NIO、Netty、epoll、Thrift、Protobuf
分布式系统中,模块间的调用通常需要用远程调用来实现。
而且随着微服务架构模式的流行,使用远程调用的比例会越来越高。
其实远程调用这种方式很早以前就出现了,早年的技术有诸如COBRA、EJB、SOAP等,但这些技术存在着用法复杂、性能差等缺点。
这些缺点限制着远程调用的普及。
这些年,随着异步IO技术、序列化技术的发展进步,以及像Zookeeper这样的集群管理服务的出现普及,妨碍远程调用普及的技术障碍逐渐被打破。
使用HTTP+JSON的方式同样可以实现模块之间的远程调用,但这种方式通常用来实现PublicAPI。
在系统内部,远程调用要求更快的速度,更小的延迟,还有还有异步调用的需求,所以HTTP+JSON通常无法满足这样的要求。
远程调用有两个重要的技术点,一个是IO技术、一个是序列化技术。
另外,远程调用还引出来另两个问题:
1.服务注册、发现、路由的问题。
这个问题的需要结合例如Zookeeper服务去解决;2.如何简化远程调用的使用,使其如同本地调用一样简单。
这个问题需要结合AOP之类的技术。
这两个问题的具体解决不在本节讨论范围之内。
2.1.IO
(这里只说SocketIO)常见的IO模型有阻塞IO、非阻塞IO和异步IO。
阻塞IO指的是如果一个线程要在Socket连接上进行某种IO操作时(读或写数据),当没有操作不可执行时(没有数据可读或无法写数据),执行操作的线程便会被挂起,操作便会被阻塞,直到操作可以执行。
这种方式的好处是业务代码编写起来很简单,缺点是资源利用率不高。
因为一个连接必须有一个线程去处理。
当有大量连接时,便会消耗大量的线程。
这个缺点放在服务器端开发领域就显得非常严重了。
非阻塞IO实现了线程的多路复用,一个线程被用来可以处理多个连接;异步IO则是由操作系统来实现IO的读写操作。
在数据ready之后,通知业务线程处理。
上面只是对阻塞IO和非阻塞IO的一个笼统的介绍。
从具体的技术来看,Linux通过epoll技术提供了对非阻塞IO的支持。
epoll是Linux内核的一个系统调用,最早在2.5.44版中被加入。
epoll的意思是eventpoll。
简单来说就是当有一个IO事件发生时,Linux内核便会通知用户。
使用方式是在创建epoll句柄之后,用户在其上不断地循环以获取新的事件(当有事件发生时)。
这些事件是来自多个连接的,从而实现了线程的多路复用。
在Java1.4中,也引入了NIO的支持(java.nio.*)。
在JavaNIOAPI中,用户的程序可以将一个连接(SelectableChannel.register(Selectorsel,intops))注册到一个Selector上(一个Selector可以有多个连接注册)。
注册之后,用户的程序便可以通过不断地循环调用Selector.selectedKeys()方法获得这个连接上的事件并进行处理(通常会使用另外的线程去处理事件,即Reactor模型)
虽然Java为NIO开发提供了良好的API支持(从1.7开始还支持了AIO),但是IO开发依旧有很高的复杂性,且JavaNIO类库的是JDK中bug较多的部分。
故不推荐普通开发者直接基于JDK开发网络IO功能,而是建议使用Netty进行开发。
关于Netty这里就不做介绍了。
2.2.序列化技术
序列化技术是远程调用的通信协议中的重要一部分,它定义了编程语言中的数据结构和数据传输协议中的数据结构之间如何相互转化。
序列化技术的性能的好坏会影响到对远程调用性能的好坏在序列化方面。
序列化技术性能的好坏主要包含两方面的含义:
一个是序列化时占用的资源(CPU、内存、所需时间);另一个是序列化之后数据的大小。
SOAPWebService和RESTWebService通常会把数据序列化成XML格式或者JSON格式。
这两种格式因为都是文本格式,所以有着良好的可读性,但是对于需要频繁使用的远程调用来说,它们的体积偏大。
所以边有了性能更好的序列化解决方案,被大家所熟知的有ProtocolBuffers和ApacheArvo。
此外,ApacheThrift的序列化的性能也很好,但是Thrift无法被当做一个单独的序列化技术被使用,而是一个完整的远程调用解决方案。
其序列化部分不太容易被剥离出来,没有完整的API被开放使用。
这里列出了常见的序列化技术的性能比较
2.3.ApacheThrift
Thrift由Facebook贡献,它是一个高性能、跨语言的RPC服务框架,适合用来实现内部服务的RPC调用。
Thrift采用通过IDL接口描述语言定义并生成服务接口,再结合其提供的服务端和客户端调用栈实现RPC功能。
1.service Calculator extends shared.SharedService {
2.
3. /**
4. * A method definition looks like C code. It has a return type, arguments,
5. * and optionally a list of exceptions that it may throw. Note that argument
6. * lists and exception lists are specified using the exact same syntax as
7. * field lists in struct or exception definitions.
8. */
9.
10. void ping(),
11.
12. i32 add(1:
i32 num1, 2:
i32 num2),
13.
14. i32 calculate(1:
i32 logid, 2:
Work w) throws (1:
InvalidOperation ouch),
15.
16. /**
17. * This method has a oneway modifier. That means the client only makes
18. * a request and does not listen for any response at all. Oneway methods
19. * must be void.
20. */
21. oneway void zip()
22.}
Thrift提供了工具,根据IDL文件,为各种编程语言(C++,Java,Python,PHP,Ruby等)生成相应的接口和数据结构。
Thrift不仅提供了传统的Request/Response方式的接口调用,也有单向的调用方式(用关键字oneway修饰)。
Thrift的序列化部分和整个框架结合紧密,并没有直接提供序列化和反序列化的接口,所以不容易和其它传输协议配合使用。
示例与解释
这里提供了一个Thrift的简单使用的示例。
其中除了ThriftClient、ThriftServer和CalculatorHandler三个类,剩下的类都是从*.thrift文件,即Thrift的IDL文件生成的。
Thrift的IDL支持namespace(即包空间)、继承等语法。
以Java为例,ThriftIDL中的service将生成接口、服务器端栈和客户端栈,这三部分又都有同步和异步两种类型。
即一个IDL文件将生成6个内部类。
客户端通过这个调用栈,在配置了传输协议、地址信息和序列化协议之后,就可以调用服务器端了。
服务器端的实现也不复杂。
当然开发
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 分布式 应用 基本 领域 开发 技术 概要