微服务

Service Mesh:重塑微服务市场

大家好,我是敖小剑,今天给大家带来的这个主题叫做 “Service Mesh:重塑微服务市场”。 刚才主持人张亮提到说,过去一年Service Mesh成为一个热词。基本上,在国内的话,我差不多是Service Mesh最早的布道师。可能如果大家之前有看相关的资料的话,应该会看到一些我的资料。我先后做过几场的演讲,做过一些技术的分享,也写过很多文章。但在此之前,这些内容可能更多的都是集中在技术领域。那今天我们会特殊一点,我们今天不谈详细的技术,不谈具体的架构,我们也不谈具体的产品。后面的这些名词,Istio/Conduit/Envoy/Linkerd/Nginmesh,这些词可能听过,可能没听过,但没问题,今天这些我们统统都不讲。我们今天要讲另外一个东西:我们会聊一聊在未来一两年之内,Service Mesh技术会在微服务相关的市场带来什么样的变化? 主要内容会是三大块:首先我们会看一下目前微服务的市场的一些现状,然后接下来我们会探讨一下它的商业模式,在第三块,我们会重点讲一下Service Mesh对PaaS的意义。 OK,第一块,微服务的现状。 我们快速过一下。 目前微服务的背景是这样,首先目前在市场上是有这么一个潮流:传统企业会慢慢向互联网技术转型,其中微服务和容器是这个技术转型的核心。这个市场比较大,大家也都看好这样一个方向,这是大的时代背景。 简单回顾一下,微服务在国内,基本上是在2015年开始兴起。2016/2017这两年在国内的基本上就是大热了。我们能看到的是,未来这一两年之内,这个热潮应该继续延续。主要还是因为微服务这个技术是用于解决实际问题的,另外它也同样适用于各种企业。这样的大背景之下,我们来看现在使用微服务的客户现状。 实际上,我们之前在谈到Service Mesh技术为什么演进的时候,我们有提到,在Service Mesh之前,第一代的侵入式微服务框架,它的门槛相对稍微高一点,典型的代表的是Dubbo,Spring Cloud。对于传统企业来说,传统企业其实缺乏一些互联网的技术基因,这些包括技术,人才,经验,还有开发流程。在实际的市场当中,我们可以看到,大多数企业,虽然他们试图在微服务方面有一些转变,但实际上,在落地的时候还是会遇到一些问题。目前第二代的Service Mesh技术其实主要是冲着解决这个问题来的。他的思路在于要想办法用Service Mesh这样一个技术来降低微服务落地的门槛,最后帮助传统企业完成整个技术转型。这是目前大的背景和现状,我们下面来详细聊一下在这个背景当中一些具体的东西。 微服务的一个痛点:落地很难。 在这个地方我放了一个冰山图,左边的有一个坐标,就是说要实现好一个微服务,技术要求大概是一个什么样子,我这边简单的画了一下。 实际上我们可以看到,就是说如果以60分为及格线的话,那很遗憾的是,虽然这个冰山我们看它的体积非常的巨大,这个市场规模是非常大的,但实际上到目前真正能够落地的,能够浮在水面上的,其实并不多。这个问题在哪里? 因为它落地太难了。 落地难的原因是门槛比较高。我们简单的罗列了一下,比如说典型的Spring Cloud,他的技术栈,我们看到的这些特性的列表。大家可以看到非常多的东西,左边这个地方Spring Cloud的各个组件。大家如果用过Spring Cloud的都会比较熟悉。当然两边并不是严格对称,这只是一个示意。 实际上在这样的一个巨大的特性列表和组件列表当中,比较头疼的是:如果你是一个新人的话,你要第一时间掌握的东西其实是非常多的。Hello Would都很简单,但是你真的要掌握,这些东西是要一个一个吃透的。 为什么这个门槛会这么高?在这里面要指出一点,就是说:解决问题的思路有点不太对。 我们先看左边这个图,我们现在如果是想要一辆汽车,那OK,可以像左边这个图一样。我们看到一辆汽车分解之后是会有多少个零件?我们现在通过类库的方式,实际去组装辆汽车,我可以给你不同的组件,不同的类库,然后告诉你这个是发动机,这个是轮胎,这个是刹车……这确实会比自己从头到尾,从每一个螺丝钉开始制造,去组装整车要轻松的多,比如说至少有个成熟的发动机,至少方向盘可以不用自己做了。但是实际上,对用户而言,必须要对整体有非常深的认识:你知道每个组件能做什么,选择合适的组件,并把他们并拢起来。这样对一个系统的了解是需要比较深的。 我们再看看右边:你组装出来的东西是什么样子?最上面这个跑车可能是所有人的梦想,对吧?但实际当中,不同的用户,他的能力是不一样的,他的投入也不一样。那他最终得到产出品,很有可能不是上面的这个让大家心动的跑车。很可能只是一个普通的大众,只能只一个QQ,甚至,其实最后一张图非常凄惨:不知道出来的会是什么,很可能是接近无法使用的产品。 在下一代的Service Mesh当中,会用其他的方式来完成这个事情。 首先通过智能代理的方式,屏蔽掉大家对底层各个组件的认知。Service Mesh会通过直接使用Sidecar的方式来完成这些功能。 从思路上说,在这个时候,最大的事情是调整战略。 我们回到需求:客户用这些东西的需求是什么?它的目标是把这个车造出来,但造出这个车的下一步,是开着它上路,去该去的地方。造车,并不是他的最终的目标,对吧?我们回到现实的例子,大家学习Spring Cloud的目标是仅仅掌握Spring Cloud吗?我们说到,做微服务的实现,是把我们体系架构在微服务之上,然后让整个体系可以更快更好的运转。所以呢,客户真正的需求是用微服务做开发,做应用开发,应用是它的核心价值。这种情况下,对于微服务系统本身的掌握,要求其实不应该那么高。 比如说我随便举个例子,我相信在座的各位,很多同学开过车对吧?你可能开车的驾驶技术很高,但是如果我们现在,举个例子说:我给你一堆组件给你组,你能不能组装成一辆车?我相信在坐的同学应该没有几个能办得到。 所以,在这个地方,在Service Mesh里面,最重要的是:我们会做一个思路的转变。我们不再以组件的方式给客户提供服务,而且直接给客户成品,而且是精心打磨的成品。这个大家梦想中的跑车,开箱即用,直接呈现在客户面前。它非常的方便,可以非常快速地使用它。他的品质是经过打磨好之后的,然后客户只需要知道该怎么驾驶就好了。 这是整个Mesh的思路。 在这个思路背后,代表了一个重要的核心理念。我们会看到,第一代的微服务将当时微服务开发的门槛降低了,在第一代微服务之前,你需要一切从零开始,你需要从每一行代码开始。换句话说,在你造整车的时候,你需要从每个螺丝钉开始,这必然是很难的。 第一代微服务至少提供了一些成熟的组件,比如说发动机OK啦,这个门槛它降低了一部分。第二代微服务,我们是希望在这个基础上,将门槛进一步降低。60分不再是及格线,我们希望将它降成30分。这个目标如果能够达成,对于期望用微服务来做技术革新的企业来说,他这个时候可以更容易地落地。大家可以想象,一场考试,及格线是60分和及格线是30分,这个时候及格率会发生质的变化,这个时候能释放出来的市场规模也会远远大于前者。 OK,这个第一阶段我们讲好。 嗯,在这个地方,我想问大家一个问题:在座的各位,有没有哪一位所在的企业是真正的将微服务落地在一线生产上的?张亮兄?OK,你这个没问题。还有没有哪一位?OK?好,这个属于冰山水面上的部分。后面还有没有其他同学?有没有同学做过尝试的?就是在你们的实际的生产当中,实际落地微服务的架构,OK,这边有些同学。 好,实际上调查的和我们预期的还是有点像的。真正的大家能够把微服务落地的,就是冰山上面露出来的一小部分。 OK,我们进行第二个探讨:Service Mesh和微服务市场模式的探讨。 我先抛出一个问题:假设现在有一个公司,他要推微服务,但它确实之前没有这样的经验,它可能也缺乏这样的人才,所以在技术能力上它会有些欠缺。那这个时候怎么办? 哪位同学能给我想一个办法?或者说如果现在你的领导和你说:我们要上微服务了,有什么办法?这个很现实的,领导明天就你定方案,然后你发现你的团队好像大家都没玩过,也都不会。请你告诉我怎么办?有没有哪个同学给我一个想法? 注:现场互动,有同学回答说,需要领导重视。 嗯,非常重视,我们明天就上! 注:现场互动,有同学继续说,招人,外包。 恩,招人和外包,还有别的吗?OK,好,这位同学至少已经找到了明天早上开始推行微服务的一些方案了。 OK,我们简单过一下,刚才这个同学这里有一个比较有意思的地方:招人。这个有个比较有意思的东西给大家轻松一下。 这个是我个人的玩笑,用于区分互联网企业的一个简单方式:当发现有些事情自己不会做,也没有合适的人手,没能力的时候怎么办?一般互联网公司的习惯都是:挖!没人是吧,看一下业界谁会,挖!挖不过来是吧,薪水乘2?OK,互联网公司一般习惯这么干。但是传统企业一般不喜欢这么干,这里还包括伪装成互联网,大家应该懂这个意思吧?嗯,他的业务有可能是互联网业务,但他的工作方式,整个运作可能是传统企业的方式。但它的业务模式可能是互联网产品。这种企业的通常情况下它的习惯是买!拿钱去买,但他能买到什么? 当然这是个玩笑,但是有时候还是挺准确的,大家可以私底下去验证一下。 那我们现在说说,能买什么? 在这个市场,能为微服务的开发提供什么样的产品,什么样的服务吗?刚才同学说了一个:外包。是的,这个很正常。确实有非常之多的外包,但还有两个,一个是咨询,教你怎么做;一个是培训,包括出书也是一种培训,现场培训是另一种。还有一种就是卖产品,微服务相关的各种产品。整个市场会提供这些产品,但我们会注意到:前三者是不一样的。咨询、培训、外包本质上是要提升客户的能力,就是让你的能力更强。如果大家记得前面的那条线的话,现在就是在你考试的时候,让你的考试能力更强。产品是帮你稍微降低一下门槛。比如我告诉你,第五道题的答案是B,你填上就好了。最终达到大家及格的目标,至少起码及格。 整个市场提供的产品,大概是这个样子。 我们聊另外一个话题,可能更有意思:为什么大家想用微服务?尤其在参加技术大会之后。平时大家苦日子过习惯了,后来某人参加了某个技术大会之后,回来就觉得:平时这苦日子过得有点惨。旁边的这个是麦粒,不知道大家有没有吃过?晒干之后脱皮直接煮着可以吃的,甚至也可以生吃。然后是非常难吃的,很难下咽,但古代,我们的祖先原来就是这么吃下来的。后来发现参加了一场大会之后,发现这个受不了,为什么呢?发现别人吃的是右边的东西。 这个叫什么?不患贫而患不均,对吧?左边这个其实也不是过不下去,但是当你看到右边之后,通常一般人都受不了了。别人告诉你说要去皮,你要磨成粉,之后你要和面,发酵,蒸,然后就有这个吃了。大家一看,开完大会之后就发现,对啊,左边这个麦粒确实没必要这么吃,对不对? 我们现在回到刚才的这个话题:咨询、培训、外包的本质是什么?

利用开源社区打造微服务生态体系

备注: 广州地区难得的一次技术分享会议。 利用开源社区打造微服务生态体系 前言 大家好,我是敖小剑,今天给大家分享的主题是”利用开源设计打造微服务生态体系”。 主要内容如下: 内容分为三个大的部分: 微服务的核心技术 目前可选的开源微服务框架 为微服务提供支撑的基础设施 需要说明的是,由于时间有限,而分享的内容数量太多,因此: 内容都只是罗列,不展开具体介绍 个人知识面有限,列举过程中范围覆盖不足有所遗漏是必然的 部分场景我会给出一些个人建议,但是请注意这些都是我的一家之言,仅供参考 下面列出的是今天将会介绍的内容,数量非常多,可谓繁星璀璨。 第一部分:核心技术 现在开始第一个部分:核心技术。 内容主要是第一排的四个技术: 进程间通讯 服务注册与发现 负载均衡 熔断 第二排的三个内容基本都会在类库或者框架中包含,通常不会单独放出来,因此我们不详细展开。 在展开讲述进程间通讯之前,额外指出一个对微服务而言及其重要的概念: 在微服务架构中,为了彻底隔绝不同服务,采用了最坚决的方案,强制要求服务之间:通过 远程访问 方式进行通讯 在这点上,微服务和以OSGi、jigsaw为代表的Java模块化方案形成鲜明对比。 进程间通讯的方式比较多,其多样性体现在两个方面: 有三种风格的解决方案:REST,RPC 和 定制 交互方式有两个维度:按照交互对象的数量分为一对一和一对多,按照应答返回的方式分为同步和异步。 两个维度组合之后的可能性如图: 目前业界常见的网络类库: 考虑到 netty 通常会是大多数人的选择,这里再展开谈一下 netty 的版本选择问题: 需要特别强调的是: netty 5.* 版本因为 ForkJoinPool 引入了太多复杂度而又未能带来明确的性能提升,已经被 netty 官方放弃,不再继续。使用 netty 5.* alpha 版本的同学请回退到 4.0 或者 4.1 版本。 Rest 研究不多,只能给出一点简单的建议。 RPC框架,业界数得上数的大概有十几种,这里只详细介绍三种,分别代表老中新三代RPC框架。 以下是个人给出的建议: 提醒一点的是:如果需要支持移动设备,如果想要用HTTTP 2 的新特性,那么就只能选择gRPC了。

PPMoney微服务之路

备注:这个内容先后讲过两次: 2016-08-13 在又拍云组织的 “Open Talk No.24 广州”做过一次线下演讲 2016-10 在中生代技术群进行了一次线上分享(第三十六期) PPmoney 微服务之路 前言 大家晚上好,今天给大家分享的内容是 PPmoney 微服务之路. 首先简单介绍一下,我是来自 ppmoney 的资深架构师 敖小剑,目前负责 ppmoney 的基础架构和服务化推进。 今天分享的内容主要有四个部分: 首先,介绍了一下为什么要选择微服务架构 其次,讲一下我们微服务框架的技术选型 第三,介绍微服务生态中的支撑体系 第四,旧有系统的迁移改造,以及开源计划 第一部分 为什么要选择微服务架构 我们先开始第一部分的内容:为什么要选择微服务架构? 先简单介绍一下我们公司——PPmoney(万惠). 4年做到600亿元,企业可以说是 野蛮生长。在快速发展的同时,沉积的问题也很多。 大多数创业公司在初期技术上是很郁闷的,没有足够的技术基础,所以早期技术栈会呈现多样化。造成多样化的原因,首先是“黑猫白猫,能上线就是好猫”:只要能把代码写出来、能上线,就OK;第二个是怎么快怎么来?包括买。举个例子,编程语言我们现在有php,.net,java,c++…… 问题随即暴露,规划不足、实施艰难;需求太多,来不及规划;变更太快,规划跟不上;还有非技术的原因比如人员变动频繁。整个野蛮生长的过程中,技术债务会越来越多,开发成本会越来越高。现在在加新的功能,会比想象中的要难得多。而且,最严重的是出现了“恶性循环”。 而对于互联网金融企业,应对市场的速度必须要足够快,否则难于立足。 如漫画中所示,我们出现几个问题: 方法不得当,开发效率非常低, 问题积累,工程师不堪重负 没有时间改进,咬牙硬扛 即使给工程师现成的改进方案,他也会拒绝接受:我们很忙,我们没有时间。 这是一个令人心酸的局面,双方都很无奈。 我们改进的方向: 首先事情要规范化,让无序的开发变成有序。无序的开发是什么概念?逮到哪就做到哪,至于用什么技术:有什么人用什么,会什么用什么。有序的开发有很重要的事情,叫做“统一”,同时简化技术栈。 第二个就是要“可重用”。之前的项目都是从头开始或者是从上一个项目里头复制过来,这里面是有很多事情没有做好的:基础类库、基础设施、基础架构。做这些最终的目标是提升大家的项目起点,所谓”不要输在起跑线上”。 第三个是“敏捷”。这个东西对我们而言做得非常不好,现在基本上是属于没有的状态。虽然各个团队都在宣称敏捷,但是实际做的不太好。 第四个就是“自动化”。这个就是我们希望能改进的一个重点,包括自动化测试、自动化部署、云技术、容器化等,解决这个问题的最终的目标:摆脱低级重复。 DevOps和每日发布是我们的最终目标,虽然从目前看差距还非常大。 我们最终的选择是推行服务化,以微服务架构为目标进行技术转型。 微服务的概念和好处这里就不展开。 第二部分 dolphin 微服务框架的技术选型 接下来我们开始第二部分的内容,讲一下我们微服务框架的技术选型。 这是 PPmoney 自行开发的微服务框架,海豚,英文名 Dolphin。希望这个框架做的敏捷、轻快、优雅,就像海豚一样。 开发工作从今年3月份刚开始,目前版本到了 0.7.*,已经在线上跑了。另外后面会提到,我们最重要的一个大系统已经基于这个框架做了重构(或者说重写),即将在10月上线。