温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

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

发布时间:2020-08-12 00:29:27 来源:ITPUB博客 阅读:118 作者:技术琐话 栏目:服务器

编者:把微服务讲的接地气的最佳作品。

一、微服务落地是一个复杂问题,牵扯到IT架构,应用架构,组织架构多个方面

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

    4.2. 阶段三的运维模式

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

    这就不是技术问题了,其实这就是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用户访问另一个服务,这样可以对高收入的用户推荐更加精品的产品,增加连带率。

    本文转自 :刘超的通俗云计算。

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


  • 向AI问一下细节

    免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

    AI