起初Web service

水平扩张

好了,通过replication解决了ledisdb数据安全题材,但将来肯定有那么一天,一台机械顶不住了,大家要考虑将ledisdb的数量举行拆分到多台机器。

  • 最简便易行的做法,hash(key) %
    num,num是机械的多寡,但那种做法在拉长或者去除机器的时候会导致rehash,导致大气的数量迁移。
  • 一致性hash,它相对于传统的hash,在增加依旧去除节点的时候,它能尽可能的少的进展多少迁移。不过到底如故有数据流动的。
  • 路由映射表,分歧于一致性hash,大家在外表自己担当掩护一张路由表,那样添加删除节点的时候只须求更改路由表就足以了,相对于一致性hash,个人感觉尤其可控。

我个人比较喜欢预分配+路由表的法门来进展水平增添,所谓预分配,就是第一我就将数据切分到n个(譬如1024)shard,伊始这个shard可以在一个node里面,随着node的加码,我们只要求迁移相关的shard,同时革新路由表就足以了。那种办法个人感觉灵活性最好,但对程序员要求较高,必要写出能半自动处理resharding的矫健代码。

好了,解决了replication,解决了水平增添,很长一段时间大家都能happy,当然坑依然挺多的,遇到了逐月再填啊。

CAP

在聊分布式从前,我们需求精晓CAP定理,因为在安插分布式系统的时候,CAP都是必须得面对的。

  • Consistency,一致性
  • Avaliability,可用性
  • Partition tolerance,分区容忍性

CAP的骨干就在于在分布式系统中,你不容许同时知足CAP,而不得不知足其中两项,但在分布式中,P是铁定存在的,所以大家统筹系统的时候就须要在C和A之间权衡。

比如,对于MySQL,它最初陈设的时候就没考虑分区P,所以很好的满足CA,所以做过MySQL
proxy方面工作的童鞋应该都知道,要MySQL帮忙分布式是何其的蛋疼。

而对此一般的NoSQL,则是赞成于选取AP,但并不是说不管C,只是允许长时间的数目不相同等,但能落得最终一致。

而对此急需强一致的系列,则会设想捐躯A来知足CP,譬如很多种类必须写多份才算成功,

API

基于wiki的定义,Web
service日常有二种架构形式,RESTful和Arbitrary(RPC,SOAP,etc)。

REST是Representational state
transfer的缩写,而满意REST架构模型的大家一般称之为Restful:

  • 行使URI来代表资源,譬如http://example.com/user/1 代表ID为1的user。
  • 选用规范HTTP方法GET,POST,PUT,DELETE等来操作资源,譬如Get http://example.com/user/1
    来获取user 1的信息,而使用Delete http://example.com/user/1
    来删除user 1。
  • 援助资源的各种表现形式,譬如上例Get中安装Content-Type为json,让服务端重返json格式的user音讯。

相持于Restful,另一种则是Arbitrary的,我不熟稔SOAP,这里就以RPC为例。

RPC就是remote procedure
call,它通过在HTTP请求中显得的指定要求调用的进度名字以及参数来与服务端进行互动。依然是地点的事例,假设大家需要取得用户的音信,可能就是那样
Get http://example.com/getuser?userid=1,
借使要刨除一个用户,没准是那样Get http://example.com/delUser?userid=1

那拔取何种架构呢?在此地,我赞成使用Restful架构模型,很大原因在于它知道起来很不难,而且达成不难,而现在进一步多的Web
service提供的API选拔的是Restful形式,从另一个下边也作证了它的风行。

就此那些Web service的接口就是那样了:

GET http://kv.com/key
DELETE http://kv.com/key
POST http://kv.com/key -dvalue
PUT http://kv.com/key -dvalue

下边POST和PUT能够等价,如果key存在,则用value覆盖,不设有则新建。

有关Web
service,这些话题太广太泛,加之自己也只理解一些一定的小圈子,所以准备从两方面入手,1,什么是Web
service,就当是概念性的牵线,让大家有个相关认识。2,则是基于一个简易的事例,告诉大家怎么构建一个Web
service服务。

从未有过关联的关键点

  • Cache,无论怎么样,cache在服务器领域都是一个老大首要的事物,用好了cache,你的劳务能处理越来越多的出现访问。facebook那篇paper
    Scaling Memcache at
    Facebook
    特意讲解了相关文化,那是纯属的干货。
  • 音讯队列,当并发量大了后来,光靠同步的API调用已经满意不断整个系统的质量要求,那时候就该MQ上场了,譬如RabbitMQ都是毋庸置疑的挑三拣四。
  • 无数过多别样的。。。。。。。那里就不列举了。

兑现一个概括的Web service

好了,上边扯了如此多,是或不是心痒痒想自己花费一个Web service?开发一个Web
service并不是那么不难的政工,尤其是事关到分布式之后。可是自己觉得一个小例子没准就能印证很多东西。当然我自认并不是Web
service的专家(那年头专家架构师太多,我只能算打酱油的),很多东西难免疏漏,并且有些布置也会含有很明显的民用色彩,即使我们有甚更好的认识,欢迎跟自己谈谈(妹子优先!)。

一个差不离的例证:KV Storage
Service,后边就叫KV吧。类似于S3,只是大家不是存文件,而是元数据。

对于KV来说,它只会提到到三种操作,倘诺用代码表示如下:

//根据指定的key获取对应的value
Get(key)

//设置key的值为value,如果key本来存在,则更新,否则新建
Put(key, value)

//删除key
Delete(key)

红薯的诚邀,决定给某大学的童鞋讲讲Web
Service相关知识,鉴于是率先次在母校献丑,所以依然安安分分的备选,先把看似逐字稿的事物写出来,然后在准备PPT吧。

Replication

对于眼前提到的Ledisdb,因为涉嫌到数量存放,本着不要把鸡蛋置于一个篮子里面的准绳,大家也不可以将数据放到一台机器下面,不然当机了就happy了。而化解那几个的点子就是replication。

深谙MySQL或者Redis的童鞋对replication应该都不会陌生,它们的replication都接纳的是异步的艺术,也就是在一段时间内不满足数量一致性,但一向能达标末了一致性。

但要是真想扶助同步的replication,咋做吧?何人叫我们容不得数据半点丢失。平日有三种做法:

  • 2PC,3PC
  • Paxos,Raft

因为那方面的坑很深,就不在累述,但是我是很推崇Raft的,比较于2PC,3PC,以及Paxos,Raft丰富简单,并且很好领会。有空子在认证呢。

而LedisDB的replication机制,可以看我这篇BLOG

标题看起来挺了不起上的,其实就是忽悠,原文在自己Blog,同步转发。

架构

好了,扯了那般多,大家也要伊始搭建大家的Web
service了。因为运用的是HTTP协议,所以我们得以直接采取现成的HTTP
server来帮我们处理HTTP请求。譬如nginx,apache,不过用go或者python直接写一个也不是特地困难的工作。

咱俩还亟需一个storage
server用来存放key-value,mysql可以,redis也行,或者自身的ledisdb,哪个人叫红薯说可以打广告的。

最开始,我们就唯有一台机械,启动一个nginx用来处理HTTP请求,然后启动一个ledisdb用来存放数据。然后开头对外happy的提供劳务了。

KV开始工作的很好,突然有一天,大家发现随着用户量的增大,一台机械处理不苏醒了。可以吗,大家在加一台机械,将nginx和ledisdb放到差其余机械上边。

而是好景不长,用户量越来越多,压力越来越大,大家需求再加机械了,因为nginx是一个无状态的服务,所以大家很容易的将其伸张到多台机械上边去运转,最外层通过DNS或者LVS来做负载均衡。不过对于有事态的服务,譬如上边的ledisdb,可不可能如此不难的处理了。好啊,我们总算要起来扯到分布式了。

相互协议

既然如此是Web
service,自然选取HTTP来做交互,比起协调已毕一套不通用的协商,或者应用谷歌(Google)Protocol
Buffers这么些的,HTTP具有太多的优势,就算它的特性稍微有点差,数据量稍微有点臃肿,但差一些所有的浏览器以及数不清的库能间接支持,想想都有点小震动了。

故此大家唯一要做的,就是安排性好我们的API,让外界更有利的利用Web service。

总结

地点只是自己对此Web
service一点浅显的理念,如若中间的知识稍微对您有用,那我早已感觉非凡心旷神怡了。但就如实践才是检查真理的唯一标准一样,理论知道的再多,还不如先弄一个Web
service来的实际,反正现在国内阿里云,腾讯云,百度云啥的都不缺,缺的只是跑在上头的好应用。

什么是Web service

率先根据Wiki的概念:A Web Service is a method of communication between
two electronic devices over a network.

一句话来说的话,Web Service就是基于互联网不一致装备之间交互通讯的一种艺术。Web
Service是一个软件服务,它提供多如牛毛API,而客户端通过Web商谈举办调用从而完毕有关的功能。

Web
service并不是一个离奇的定义,相反从很早的分布式统计,到网格计算,到现行的云,都或多或少的享有Web
service的阴影。只不过随着近几年一浪高过一浪的网络热潮以及谷歌(Google),亚马逊等营业所的奋力拉动,Web
service变得愈加流行。

越是多的店家先河提供Web service,而还要又有更加多的商号根据这几个Web
service提供了更加上层的Web service。

亚马逊(Amazon)的S3(Simple Storage
Service)是一个文书存储服务,用户通过S3将文件存放到亚马逊的服务器上面,亚马逊负责确保该公文的安全(包含不被旁人取得,不丢掉等)。而Drew
休斯敦则在S3的基本功上,构造了一个令人好奇的一道网盘:Dropbox,同时,Dropbox又将有关API提供出去,供其余的Application使用其一同服务。

可以看看,正是因为有了越多的Web
services,才让我们今天的互联网生活变得越来越精粹。

网站地图xml地图