|
消息中间件 关键字：Kafka、RabbitMQ 在分布式系统中，消息中间件的重要性越来越明显。消息中间件可以解耦模块、提供异步调用功能、消息持久化、消息削峰。已有的如 Apache ActiveMQ 无法满足新的需要，于是出现了如 RabbitMQ、Apache Kafka 等新型的消息中间件产品。 Apache Kafka Apache Kafka 充分利用了机械磁盘顺序读写速度快的特点，在接受消息之后同步地写入到磁盘中，保证数据可靠性的同时，也保证了非常快的速度。每个 Kafka 集群上都有多个 Topic，Topic 相当于一个 category，消费者可以订阅一个或多个 Topic。每个 Topic 由多个 Partition 组成。消息被顺序的添加到 Partition 中，每条消息有一个唯一的、有序的 ID，这个 ID 被称为 Offset。Consumer 需要维护自己消费到的消息的位置 (Offset)。 Apache Kafka 不同于传统的消息中间件，它采用“拉”消息模式，而不是传统的“推”消息模式。即客户端需要主动从消息中间件获取消息，好处是客户端可以更好地控制请求量。 Queue 模式和 Topic 模式 传统消息队列服务中有队列模式和发布订阅模式两种模式，前者一条消息只会被一个消费者消费;后者一条消息会发布给所有的订阅这个 Topic 的消费者。在 Kafka 中，这两种模式是使用一种方式 —— 消费者组来实现的。在同一个消费者组中的不同消费者不会受到相同的消息。如果想实现发布订阅模式，消费者必须处于不同的消费者组中。 Kafka 集群 RabbitMQ RabbitMQ 是一个使用 Erlang 开发的 AMQP (Advanced Message Queue Protocol) 实现。现在 RabbitMQ 是由 VMware 旗下的 SpringSource 负责开发。AMQP 是一个语言无关的消息队列协议。在 RabbitMQ 中，有三个概念：Exchange、Queue 和 Route key。Exchange 用来标示生产者，Queue 用来标示消费者，而 Route key 用来关联这两者。RabbitMQ 中这种方式提供了更灵活的应用模式。 分布式文件系统 块存储与对象存储 块存储是将一块裸盘提供给客户使用，但是这块裸盘可能是来自一块物理硬盘，也有可能是多块，或是来自不同服务器上的硬盘。对象存储提供了更高级的接口，通过这些接口可以读写文件以及相关的元数据。其中的元数据包含了文件每一个块的存储信息。通过文件元数据，文件可以被并行地操作。 分布式文件系统的高可用 为了保证数据的安全，分布式文件系统通常会将文件复制为三份。这三份数据会位于不同的服务器上，对应要求更高的系统，比如公有云存储。其中的一份数据会放置在另一个机房中，以保证即便整个机房出现故障，整个文件系统仍是可用的。 Ceph Ceph 目前是 OpenStack 的一个组件，提供了块存储和对象存储的功能。 GridFS GridFS 是 MongoDB 的一部分。用来存储超过 BSON 大小限制(16MB)的文件。GridFS 将文件分成一个个部分，分开存储。 FastDFS FastDFS 是一个轻量的分布式文件系统，适合存储中小文件(对象存储)。FastDFS 的跟踪服务器不负责记录文件的元信息。文件的具体存储位置等信息包含在返回给用户的 File ID 中。 分布式内存 内存是新的硬盘，硬盘是新的磁带 -- Jim Gray Hazelcast Hazelcast 是一个面向 Java 的分布式内存解决方案，提供了丰富的功能特性。实现了诸如分布式 Java 集合类、分布式锁、分布式 ExecutorService 实现等等。但现实往往是残酷的，Hazelcast 在实际应用中存在大量的缺陷。详见 “hazelcast的坑爹事” Memcached Memcached 是老牌的“分布式”缓存解决方案。分布式之所以加引号，是因为 Memcached 服务器端本身并不支持分布式，服务器端每个节点之间并不会相互通信。分布式的支持需要客户端来实现。早期的内存分布式是通过节点之间复制来实现的，但这种方式却限制了可伸缩性。这也是因为诸如 Terrecotta 这样的内存分布式解决方案没有成为主流的原因。 Redis Gemfire 分布式数据库 关系型数据库 在大规模的分布式应用中，单库或者简单的读写分离已经无法满足要求，因此必须对数据库进行水平和垂直的划分和分库分表。在对数据库进行分库分表之后，应用对数据库的访问便不再是一件简单的事情了。应用在进行一次数据库操作时，其所对应的数据库的地址和表名必须通过某种逻辑运算才能得到。例如，ID 从1到1,000,000的User数据是数据库1的User_1表中，ID从1,000,001到2,000,000的User数据在数据库1的 User_2表中，而其它的User数据又会在不同的数据库的不同的表中。同时，还要考虑主从数据库，读写分离的问题。这样的数据库使用方式会使数据操作变得极为复杂，也会增加数据迁移，增容扩容时的难度。 对于这样复杂的问题，靠应用自己解决显然是不合适的。所以各家分布式应用的使用大户——互联网厂商，都自己实现了相应的解决方案。这些解决方案可分为中间间方式和框架方式，前者作为数据库访问的代理，使得分布式的数据库对应用是透明的。后者作为一个框架嵌入到应用中，也能起到类似的作用。这两种方式各有优劣，分别适合不同的场合。 搜狗 Compass，阿里 TDDL、Cobar NoSQL 大部分 NoSQL 虽然对分布式的支持是友好的，但这并不意味着使用这些 NoSQL 数据库就可以轻轻松松地实现一个集群。例如著名的 Key/Value 数据库 Redis。它 3.0 之前一直没有官方的集群方案，所以各个大规模使用 Redis 都需要自己实现分布式方案，例如 Twitter 的 Twemproxy、豌豆荚的 Codis 等等。 在实现数据的分布式解决方案的时候，有一个算法是最常被使用的 —— 一致性哈希算法，这里只是简单提一下，不做进一步介绍。 虚拟化技术 关键字：OpenStack、Docker、容器技术虚拟化技术是提高硬件利用率的重要手段。虚拟化技术是实现云计算的重要技术。虚拟化技术的最底层是各种硬件的虚拟化，如 CPU 虚拟化、内存虚拟化、存储虚拟化、网络虚拟化等等。然后再基于这些技术，构建出各种虚拟机技术。然后各个厂商又基于虚拟机技术和其它虚拟化技术构建出 IaaS、PaaS 和 SaaS 等平台和软件产品。 OpenStack OpenStack 这个开源项目包含了一系列用于 IaaS 平台搭建的组件的合称。这些组件包含用于网络虚拟化的 Neutron、提供存储虚拟化的 Ceph 和 Swift、以及提供例如镜像管理、控制面板等功能的诸多组件。OpenStack 本身并不提供虚拟化技术，而是通过支持诸多现有的虚拟化技术，例如 KVM，并在此之上提供一系列构建 IaaS 解决方案的技术。OpenStack 中的组件可以灵活搭配使用，并且因为开源的原因，使用者可以对其进行自定义或二次开发。但是也是因为这个原因，任何厂商想要成功使用 OpenStack 必须有一个强大的技术团队做后盾。这也是目前 OpenStack 技术发展遇到的最大困难。 Docker 严格说来 Docker 并不是一个虚拟化技术，但是因为 Docker 能够提供给使用者一种轻量化的虚拟机的使用体验，所以也将 Docker 列在这里。Docker 是一个容器技术，它通过 Linux 内核的支持，使不同的进程可以相互隔离并做到资源的限制，从而实现了部分的虚拟机资源隔离的需要。Docker 相比较虚拟机的优势在于轻量和系统资源使用效率接近于实体机。因为现在随着需求的发展和技术的进步，服务器端应用向着一种轻量化和越来越分布式的方向发展。虚拟机这样重量级的技术对于小而多的应用来说便不再合适，这也是 Docker 这样的容器技术近些年迅速发展并呈现火热状态的重要原因。 Docker 和前面提到的 OpenStack 是两个不同层面的技术，两者并不冲突。现在 OpenStack 和 Docker 社区正在紧密合作(容器不会取代OpenStack，但二者如何深度整合?)。 分布式系统之负载均衡 HAProxy HAProxy 是一个高性能的 TCP 和 HTTP 反向代理代理和负载均衡服务器。可用反向代理和负载均衡还有 Nginx。Niginx 更偏向于 HTTP 协议。另外 Varnish 和 Squid 可以作为前端的代理，但是它们更偏重缓存功能 更上一层 服务编排：注册、发现和路由 结合技术：配置管理、远程调用等 有些类似早年的 JNDI。即一个应用去远程访问另外一个应用时，只需知道它所要访问的应用的名称、版本等信息，即可调用成功。不需要考虑它所要调用的应用的具体地址。 云操作系统 结合技术：虚拟机、容器技术、网络虚拟化、配置管理、消息队列 Apache Mesos、Google Berg、腾讯 Gaia、百度 Matrix 总结 就像上面所提到的，上面的这些技术之间都是你中有我，我中有你的关系，或者有着相类似的设计思想。掌握它们，基本不去使用，也会对你设计开发能力的提高大有裨益。 博文出处：http://my.oschina.net/lifany/blog/423082
【编辑推荐】 【责任编辑：Ophira TEL：（010）68476606】 |
|
|
