必赢网址-必赢437-www437com

热门关键词: 必赢网址,必赢437,www437com

谈谈服务治理,服务治理概述

  本来应一个可爱帅气的编辑之邀,要写一本书《静儿的互联网服务治理私房菜》。想选服务治理的题材,想急着签协议就写了一个很匆忙的目录和例章。写书本是计划了很久的一件事情。现在反而有些犹豫了。我是不是应该把脚步放慢一些,再稳一些。我是不是应该自己先写了一部分,再考虑签约出版的事情。要做的事情太多了,比如:家里首先有帅气的男神要陪,人家老是计划着去这旅游,那旅游的。还有可爱的小鲜肉要陪,每天他都在长大,总觉得下一天他就没有今天可爱了。我记得他1岁多的时候,抱着他在院子里玩,总是觉得6个月大的小宝宝好可爱。然后现在又觉得他2岁之前胖嘟嘟的好可爱。话说很多朋友反馈说我最近不跑题,不秀恩爱了图片 1

  本期我们组的技术分享,打算跟大家讲讲服务治理。我在上篇文章中介绍了我们美团.点评北京总部用的OCTO框架,其实在上海点评部门用的是另一套Pigeon。这两套框架都很重。这是和我们的业务有关的,其实服务治理这个东西都创业公司到成熟的大公司都在用,只是做到的程度不同。

  哎,再纠结一下要不要现在出版。例章自己不满意,我要换掉。正好放到这里,让大家给点意见。写了十几页,今天先放一部分。对了,编辑让我不要手绘,用作图工具。我记得我看过一本外国大牛的书,啥来着,挺有名的,里面全是草稿纸似的作图。大家觉得呢,我应该用作图工具吗?谁能帮我想起来那本书的名字吗?

  先说说服务治理的边界。本质上任何能提升服务可用性,性能,让服务更稳定等等,只要是能让服务运行的更好,都属于服务治理的范畴。服务治理比较常见的话题:服务发现,服务变更管理,服务监控,服务扩容缩容,服务自我保护,服务降级,服务授权防攻击,服务上线验证和灰度发布,服务问题定位和跟踪,服务负载,服务实例的调度等等。

第1章 服务治理概述

  说服务治理就要先聊聊服务。从业务角度而言,服务是一个可重复的任务。我是个做业务的,业务可以被粗粒度的划分为一系列粗粒度的服务和流程。这本质上符合SOA架构的风格,而现在比较流行的微服务出现实际上应当归功于SOA原则的成功。而微服务将服务划分的更细,更多,会导致出问题的概率变大。这时候,服务治理的手段没有进步的话,实际上服务的压力是变大了。所以大家在选择架构的时候,需要按照自己的业务发展现状和趋势合理的辩证的做决断。就好像我在上篇文章里举的例子:如果要建一间房子,可能随便建个土房子或者茅草房子就能用几十年,但是随着规模的扩大,建成四合院就要讲究格局,建成一个小区,建成一座城市,就需要运用各种工程学的知识更加统筹的规划。这就是为什么我要来美团。我在乐视其实过得很舒服,很自由。因为我家微微一笑很倾城的男神老大不仅英俊帅气,智商情商双高,而且管理风格open,很合适我这种有自己想法的下属。但是乐视各个部门更像是一个村落,大家都在各自建各自的房子,好处是有才能的人可以比较自由的发挥,缺点是格局不够统一,各个部门做了很多重复的工作。所以乐视出来的人有水平非常高的,也有水平非常一般的。我个人觉得如果你个人能力非常好,可以去乐视试一试,说不定可以发挥自己的潜能。但是对于我而言,我发现了自己格局的问题,如果我坚持还是要去阿里的话,到那边也是个拧螺丝的,平台很好,但是能不能发挥是个问题。而来美团,我至少能够得到的保证是:完成一个从对工作负责到对结果负责的转变。什么意思呢?我来这边,我们架构师说我来之前,他需要找各个开发去告诉他们我们的工作,每个开发都听明白了,然后回到工位完成了自己的那份工作。结果中间衔接的部分职责模糊的部分就很可能被漏掉了。我来了,我的工作是对结果负责,那么涉及到内部职责的划分,上下游的对接和业务了解。任何能让结果变得更好的事情都属于我的职责范围。这和服务治理的理念不谋而合,这就是为什么我要来研究服务治理。

  服务治理是伴随着服务的概念同步产生的,只是随着SOA(面向服务架构),微服务架构的流行,服务治理的地位日益凸显,大家也开始越来越重视这个话题。笔者在实际工作过程中发现很多人对服务治理的认知停留在服务治理框架的层面,思想受到框架的限制,本章内容主要带领大家对服务治理有个清晰明确的概念。

  我也自己创过业,做的最小的项目本质上也用到了服务治理相关的东西,就是nginx。nginx本身不处理业务逻辑。它做了什么事情呢?服务发现,负载均衡。我自己觉得与其将其归类为一个具体的服务组件,划分为服务治理组件更为合适。nginx的服务发现大家都知道是在upstream里配置的,可以做DNS动态解析。服务更变修改配置文件后用nginx -s reload让nginx发现最新的配置,可以说是一个轻巧简单的服务发现机制。nginx的负载均衡大家说的比较多了,我就不详述了。但是它做负载均衡的前提是它还实现了服务的分离。它可以将前端静态请求转发到静态服务上,动态api转发到api服务上,rpc调用转发到rpc服务上。nginx的服务治理能力还体现在所有这些分离的服务,请求的log都是走nginx服务,我们可以更方便的观察监控请求,所以相对于分散的服务有更好的治理能力的。

1.1 服务、服务治理的概念

  服务再大一些,就是用到另一个大家熟知的东西,就是zookeeper来做配置变更管理。有一本书叫做《从paxos到zookeeper》讲了zookeeper的内部实现,怎样保证其一致性和分区一致性。但是zookeeper的最大问题是网络抖动对其的影响。为了解决这个问题,美团.点评的OCTO服务治理框架采用了本地代理。

  周末做了一道“水果什锦紫薯彩椒鸭”。盛菜的容器是大半个火龙果挖去果肉后的壳,彩椒水果的点缀色彩绚丽,卖相还不错。发到朋友圈,有朋友回复说:“静儿的味道有点复杂。”还有朋友回复很直接:“这样搭配真的好吃么。”下面公开我的私房食谱,味道大家自己来评判吧。

  服务自动扩容缩容对于美团.点评这样的,交易时间高峰基本在中午11点到13点。这段时间交易量大,实际上是需要扩容来保证的。交易量低的时段机器闲置造成很大的资源浪费。这种自动扩容缩容需要区分是正常的请求扩容还是异常请求扩容。一个环节扩容会不会给其他环节造成更大的压力,反而压垮整个链路。如果是异常请求,这个时候应该采用的是拒绝请求。比如有数据库慢查询,显示调用结果是线程池满了,要排队。如果这时候采取了扩容,反而压垮数据库。这时候应该是报警而不是扩容。

  首先将鸭肉洗净用刀背拍打至肉质松软,切成小块备用。紫薯半个,切成小块备用。红色黄色彩椒各四分之一个,切小块备用。紫薯过油炸熟。炒锅留少许油,爆葱姜出香味后放入切好的鸭肉和炸过的紫薯,放盐,葡萄酒,煸炒至熟。放入彩椒,翻炒两下出锅。少凉后放入火龙果壳内,上摆水果点缀。

  在乐视的时候,阿里的阳哥自己开发了一个基于redis的异常日志收集器。这个其实也属于服务治理的范畴,这是一个统一的服务监控报警机制。报警是触发门槛很低的异常处理机制。所以我在乐视的时候邮箱,手机短信报警太多了,我就想换了工作再也不用收这些报警了。结果,好吧,换工作后多了N倍。异常再达到一定量级,可能会触发过载保护。过载保护再不解决问题就要降级了。我之前博客里也提到的乐视用guava的RateLimiter做了限流,这就是过载保护的一种方式。

  鸭肉活血,是养生的美食,但是肉质硬,所以要拍打松软。鸭肉腥味重,所以做北京烤鸭用的烤木都是果木,自带果香,还有去腥的作用。我这里采用葡萄酒,去腥去油腻效果很赞。紫薯是高淀粉的,油炸过后香味诱人,还能进一步去腥。放入彩椒荤素搭配,两下就出锅减少维生素C损失。上摆水果,火龙果壳,好看又开胃,进一步吸收腥味。

   

  怎么样?分解来看之后是不是没有大杂烩的感觉了?现在互联网开发的系统越来越复杂,怎样让系统服务各司其职,共同承载系统的运行任务呢。美食靠烹饪,服务靠治理。

  大约在2010年时,zookeeper还不是很流行,当时我们团队从零开始开发一个商务领域的社交网站。我们的数据库使用的是主备数据库,我甚至自己写了一个socket发报文去监听数据库状态。各个业务分支都要依赖我的这个服务获取数据库配置。开发阶段,一开始不稳定,经常数据库连接无法获取,所有的开发人员都从座位上站起来眼巴巴的等待我解决问题。

本文由必赢网址发布于印刷出版,转载请注明出处:谈谈服务治理,服务治理概述

您可能还会对下面的文章感兴趣: