叁叁肆

这个世界会好吗

453篇博客

致传统企业朋友:不够痛就别微服务,有坑 (2)

叁叁肆2018-11-07 09:30

此文已由作者刘超授权网易云社区发布。

欢迎访问网易云社区,了解更多网易技术产品运营经验。


3.4. 阶段二有什么问题吗?


其实大部分的企业,到了这个阶段,已经可以解决大部分的问题了。

能够做到架构SOA化,基础设施云化的公司已经是传统行业在信息化领域的佼佼者了。

中台开发组基本能够解决中台的能力复用问题,持续集成也基本跑起来了,使得业务开发组的迭代速度明显加快。

集中的中间件组或者架构组,可以集中选型,维护,研究消息队列,缓存等中间件。

在这个阶段,由于业务的稳定性要求,很多公司还是会采用Oracle商用数据库,也没有什么问题。

实现到了阶段二,在同行业内,已经有一定的竞争优势了。


3.5. 什么情况下才会觉得阶段二有问题?


我们发现,当传统行业不再满足于在本行业的领先地位,希望能够对接到互联网业务的时候,上面的模式才出现新的痛点。

对接互联网所面临的最大的问题,就是巨大的用户量所带来的请求量和数据量,会是原来的N倍,能不能撑得住,大家都心里没底。

例如有的客户推出互联网理财秒杀抢购,原来的架构无法承载近百倍的瞬间流量。

有的客户对接了互联网支付,甚至对接了国内最大的外卖平台,而原来的ESB总线,就算扩容到最大规模(13个节点),也可能撑不住。

有的客户虽然已经用了Dubbo实现了服务化,但是没有熔断,限流,降级的服务治理策略,有可能一个请求慢,高峰期波及一大片,或者请求全部接进来,最后都撑不住而挂一片。

有的客户希望实现工业互连网平台,可是接入的数据量动辄PB级别,如果扛的住是一个很大的问题。

有的客户起初使用开源的缓存和消息队列,分布式数据库,但是读写频率到了一定的程度,就会出现各种奇奇怪怪的问题,不知道应该如何调优。

有的客户发现,一旦到了互联网大促级别,Oracle数据库是肯定扛不住的,需要从Oracle迁移到DDB分布式数据库,可是怎么个迁移法,如何平滑过渡,心里没底。

有的客户服务拆分之后,原来原子化的操作分成了两个服务调用,如何仍然保持原子化,要不全部成功,要不全部失败,需要分布式事务,虽然业内有大量的分布式方案,但是能够承载高并发支付的框架还没有。

当出现这些问题的时候,才应该考虑进入第三个阶段,微服务化


四、阶段三:组织DevOps化,架构微服务化,基础设施容器化


             



4.1. 阶段三的应用架构


从SOA到微服务化这一步非常关键,复杂度也比较高,上手需要谨慎。

为了能够承载互联网高并发,业务往往需要拆分的粒度非常的细,细到什么程度呢?我们来看下面的图。


             


在这些知名的使用微服务的互联网公司中,微服务之间的相互调用已经密密麻麻相互关联成为一个网状,几乎都看不出条理来。

为什么要拆分到这个粒度呢?主要是高并发的需求。

但是高并发不是没有成本的,拆分成这个粒度会有什么问题呢?你会发现等拆完了,下面的这些措施一个都不能少。

  • 要使用消息队列,将原来连续调用的多个服务异步化为监听消息队列,从而缩短核心逻辑

  • 服务之间要设定熔断,限流,降级策略,一旦调用阻塞应该快速失败,而不应该卡在那里,处于亚健康状态的服务要被及时熔断,不产生连锁反应。非核心业务要进行降级,不再调用,将资源留给核心业务。要在压测到的容量范围内对调用限流,宁可慢慢处理,也不用一下子都放进来,把整个系统冲垮。

  • 拆分成的服务太多了,没办法一个个配置,需要统一的一个配置中心,将配置下发

  • 拆分成的服务太多了,没办法一个个看日志,需要统一的日志中心,将日志汇总

  • 拆分成的服务太多了,很难定位性能瓶颈,需要通过APM全链路应用监控,发现性能瓶颈,及时修改

  • 拆分成的服务太多了,不压测一下,谁也不知道到底能够抗住多大的量,因而需要全链路的压测系统。

应用层需要处理这十二个问题,最后一个都不能少,实施微服务,你做好准备了吗?你真觉得攒一攒springcloud,就能够做好这些吗?


4.2. 阶段三的运维模式


业务的微服务化改造之后,对于运维的模式是有冲击的。


            

如果业务拆成了如此网状的细粒度,服务的数目就会非常的多,每个服务都会独立发布,独立上线,因而版本也非常多。

这样环境就会非常的多,手工部署已经不可能,必须实施自动部署。好在在上一个阶段,我们已经实施了自动部署,或者基于脚本的,或者基于镜像的,但是到了微服务阶段都有问题。

如果基于脚本的部署,脚本原来多由运维写,由于服务太多,变化也多,脚本肯定要不断的更新,而每家公司的开发人员都远远多于运维人员,运维根本来不及维护自动部署的脚本。那脚本能不能由开发写呢?一般是不可行的,开发对于运行环境了解有限,而且脚本没有一个标准,运维无法把控开发写的脚本的质量。

基于虚拟机镜像的就会好很多,因为需要脚本做的事情比较少,大部分对于应用的配置都打在镜像里面了。如果基于虚拟机镜像进行交付,也能起到标准交付的效果。而且一旦上线有问题,也可以基于虚拟机镜像的版本进行回滚。

但是虚拟机镜像实在是太大了,动不动几百个G,如果一共一百个服务,每个服务每天一个版本,一天就是10000G,这个存储容量,谁也受不了。

这个时候,容器就有作用了。镜像是容器的根本性发明,是封装和运行的标准,其他什么namespace,cgroup,早就有了。

原来开发交付给运维的,是一个war包,一系列配置文件,一个部署文档,但是由于部署文档更新不及时,常常出现运维部署出来出错的情况。有了容器镜像,开发交付给运维的,是一个容器镜像,容器内部的运行环境,应该体现在Dockerfile文件中,这个文件是应该开发写的。

这个时候,从流程角度,将环境配置这件事情,往前推了,推到了开发这里,要求开发完毕之后,就需要考虑环境部署的问题,而不能当甩手掌柜。由于容器镜像是标准的,就不存在脚本无法标准化的问题,一旦单个容器运行不起来,肯定是Dockerfile的问题。

而运维组只要维护容器平台就可以,单个容器内的环境,交给开发来维护。这样做的好处就是,虽然进程多,配置变化多,更新频繁,但是对于某个模块的开发团队来讲,这个量是很小的,因为5-10个人专门维护这个模块的配置和更新,不容易出错。自己改的东西自己知道。

如果这些工作量全交给少数的运维团队,不但信息传递会使得环境配置不一致,部署量会大非常多。

容器作用之一就是环境交付提前,让每个开发仅仅多做5%的工作,就能够节约运维200%的工作,并且不容易出错。


             


容器的另外一个作用,就是不可改变基础设施。

容器镜像有个特点,就是ssh到里面做的任何修改,重启都不见了,恢复到镜像原来的样子,也就杜绝了原来我们部署环境,这改改,那修修最后部署成功的坏毛病。

因为如果机器数目比较少,还可以登录到每台机器上改改东西,一旦出了错误,比较好排查,但是微服务状态下,环境如此复杂,规模如此大,一旦有个节点,因为人为修改配置导致错误,非常难排查,所以应该贯彻不可改变基础设施,一旦部署了,就不要手动调整了,想调整从头走发布流程。

这里面还有一个概念叫做一切即代码,单个容器的运行环境Dockerfile是代码,容器之间的关系编排文件是代码,配置文件是代码,所有的都是代码,代码的好处就是谁改了什么,Git里面一清二楚,都可以track,有的配置错了,可以统一发现谁改的。


4.3. 阶段三的组织形态


到了微服务阶段,实施容器化之后,你会发现,然而本来原来运维该做的事情开发做了,开发的老大愿意么?开发的老大会投诉运维的老大么?

这就不是技术问题了,其实这就是DevOps,DevOps不是不区分开发和运维,而是公司从组织到流程,能够打通,看如何合作,边界如何划分,对系统的稳定性更有好处。



             


其实开发和运维变成了一个融合的过程,开发会帮运维做一些事情,例如环境交付的提前,Dockerfile的书写。

运维也可以帮助研发做一些事情,例如微服务之间的注册发现,治理,配置等,不可能公司的每一个业务都单独的一套框架,可以下沉到运维组来变成统一的基础设施,提供统一的管理。

实施容器,微服务,DevOps后,整个分工界面就变成了下面的样子。



             


在网易就是这个模式,杭州研究院作为公共技术服务部门,有运维部门管理机房,上面是云平台组,基于OpenStack开发了租户可自助操作的云平台。PaaS组件也是云平台的一部分,点击可得,提供SLA保障。容器平台也是云平台的一部分,并且基于容器提供持续集成,持续部署的工具链。

微服务的管理和治理也是云平台的一部分,业务部门可以使用这个平台进行微服务的开发。

业务部门的中间件组或者架构组合云平台组沟通密切,主要是如何以正确的姿势使用云平台组件。

业务部门分前端组,业务开发组,中台开发组。


五、如何实施微服务,容器化,DevOps


实施微服务,容器化,DevOps有很多的技术选型。

其中容器化的部分,Kubernetes当之无愧的选择。但是Kubernetes可不仅仅志在容器,他是为微服务而设计的。对于实施微服务各方面都有涉及。

详细分析参加为什么 kubernetes 天然适合微服务


             

但是Kubernetes对于容器的运行时生命周期管理比较完善,但是对于服务治理方面还不够强大。

因而对于微服务的治理方面,多选择使用Dubbo或者SpringCloud。使用Dubbo的存量应用比较多,相对于Dubbo来讲,SpringCloud比较新,组件也比较丰富。但是SpringCloud的组件都不到开箱即用的程度,需要比较高的学习曲线。


             


因而基于Kubernetes和SpringCloud,就有了下面这个微服务,容器,DevOps的综合管理平台。包含基于Kubernetes的容器平台,持续集成平台,测试平台,API网关,微服务框架,APM应用性能管理。


             


主要为了解决从阶段一到阶段二,或者阶段二到阶段三的改进中的痛点。

下面我们列举几个场景。

场景一:架构SOA拆分时,如何保证回归测试功能集不变


前面说过,服务拆分后,最怕的是拆完了引入一大堆的bug,通过理智肯定不能保证拆分后功能集是不变的,因而需要有回归测试集合保证,只要测试集合通过了,功能就没有太大的问题。

回归测试最好是基于接口的,因为基于UI的很危险,有的接口是有的,但是UI上不能点,这个接口如果有Bug,就被暂时隐藏掉了,当后面有了新的需求,当开发发现有个接口能够调用的时候,一调用就挂了。


有了基于Restful API的接口测试之后,可以组成场景测试,将多个API调用组合成为一个场景,例如下单,扣优惠券,减库存,就是一个组合场景。

另外可以形成测试集合,例如冒烟测试集合,当开发将功能交付给测试的时候,执行一下。再如日常测试集合,每天晚上跑一遍,看看当天提交的代码有没有引入新的bug。再如回归测试集合,上线之前跑一遍,保证大部分的功能是正确的。


场景二:架构SOA化的时候,如何统一管理并提供中台服务


当业务要提供中台服务的时候,中台服务首先希望能够注册到一个地方,当业务组开发业务逻辑的时候,能够在这个地方找到中台的接口如何调用的文档,当业务组的业务注册上来的时候,可以进行调用。


在微服务框架普通的注册发现功能之外,还提供知识库的功能,使得接口和文档统一维护,文档和运行时一致,从而调用方看着文档就可以进行调用。

另外提供注册,发现,调用期间的鉴权功能,不是谁看到中台服务都能调用,需要中台管理员授权才可以。

为了防止中台服务被恶意调用,提供账户审计功能,记录操作。


场景三:服务SOA化的时候,如何保证关键服务的调用安全


有的服务非常关键,例如支付服务,和资金相关,不是谁想调用就能调用的,一旦被非法调用了,后果严重。

在服务治理里面有路由功能,除了能够配置灵活的路由功能之外,还可以配置黑白名单,可以基于IP地址,也可以基于服务名称,配置只有哪些应用可以调用,可以配合云平台的VPC功能,限制调用方。


场景四:架构SOA化后,对外提供API服务,构建开放平台

         

架构SOA化之后,除了对内提供中台服务,很多能力也可以开放给外部的合作伙伴,形成开放平台。例如你是一家物流企业,除了在你的页面上下单寄快递之外,其他的电商也可以调用你的API来寄快递,这就需要有一个API网关来管理API,对接你的电商只要登录到这个API网关,就能看到API以及如何调用,API网关上面的文档管理就是这个作用。

另外API网关提供接口的统一认证鉴权,也提供API接口的定时开关功能,灵活控制API的生命周期。


场景五:互联网场景下的灰度发布和A/B测试


接下来我们切换到互联网业务场景,经常会做A/B测试,这就需要API网关的流量分发功能。

例如我们做互联网业务,当上一个新功能的 时候,不清楚客户是否喜欢,于是可以先开放给山东的客户,当HTTP头里面有来自山东的字段,则访问B系统,其他客户还是访问A系统,这个时候可以看山东的客户是否都喜欢,如果都喜欢,就推向全国,如果不喜欢,就撤下来。


场景六:互联网场景下的预发测试


这个也是互联网场景下经常遇到的预发测试,虽然我们在测试环境里面测试了很多轮,但是由于线上场景更加复杂,有时候需要使用线上真实数据进行测试,这个时候可以在线上的正式环境旁边部署一套预发环境,使用API网关将真实的请求流量,镜像一部分到预发环境,如果预发环境能够正确处理真实流量,再上线就放心多了。


场景七:互联网场景下的性能压测


互联网场景下要做线上真实的性能压测,才能知道整个系统真正的瓶颈点。但是性能压测的数据不能进真实的数据库,因而需要进入影子库,性能压测的流量,也需要有特殊的标记放在HTTP头里面,让经过的业务系统知道这是压测数据,不进入真实的数据库。

这个特殊的标记要在API网关上添加,但是由于不同的压测系统要求不一样,因而需要API网关有定制路由插件功能,可以随意添加自己的字段到HTTP头里面,和压测系统配合。


场景八:微服务场景下的熔断,限流,降级


微服务场景下,大促的时候,需要进行熔断,限流,降级。这个在API网关上可以做,将超过压测值的流量,通过限流,拦在系统外面,从而保证尽量的流量,能够下单成功。

在服务之间,也可以通过微服务框架,进行熔断,限流,降级。Dubbo对于服务的控制在接口层面,SpringCloud对于服务的管理在实例层面,这两个粒度不同的客户选择不一样,都用Dubbo粒度太细,都用SpringCloud粒度太粗,所以需要可以灵活配置。


             


场景九:微服务场景下的精细化流量管理。


             


在互联网场景下,经常需要对于流量进行精细化的管理,可以根据HTTP Header里面的参数进行分流,例如VIP用户访问一个服务,非VIP用户访问另一个服务,这样可以对高收入的用户推荐更加精品的产品,增加连带率。


相关阅读:致传统企业朋友:不够痛就别微服务,有坑 (1)


网易云计算基础服务深度整合了 IaaSPaaS 及容器技术,提供弹性计算、DevOps 工具链及微服务基础设施等服务,帮助企业解决 IT、架构及运维等问题,使企业更聚焦于业务,是新一代的云计算平台,点击可免费试用



免费体验云安全(易盾)内容安全、验证码等服务

更多网易技术、产品、运营经验分享请点击