<强>无服务器准备:
近两年无服务器是软件开发热门话题.AWS引领这项技术且在不断进步,而各云厂商都具有自己的技术标准,如果要做各个云厂商之前无缝移植,从目前看来几乎不可能,不过我相信对这一技术的创新未来有可能会出现第三方无缝对接或者统一标准,我们期待有这么一天。
由于无服务具备以下突出的优点,如:<强> 1。实现业务快速上线,2。无须运维人员维护基础资源,降低运维成本,3。系统级安全性更高,4。降低开发成本,5。适合微服务框架,在这些优点吸引下以及大云厂商推荐下,很多用户就会试着把他们原来在On-prem的业务使用重构的方式往λ迁移,而这些尝试首先必须要求用户的人员能够在微服务基础上继续拆分成函数的能力,能够把业务做成无状态。
业务演进图1
<强>从原来巨型业务重构到函数,这对开发人员要求越来越高,需要开发人员对业务进行细粒度拆分强,以满足这种新技术的要求。
<>强实践分享:
由于客户原来在本地的应用已经无法满足业务的日益扩展,需要对原来的应用进行代码重构后上云。客户没有具备技术很强架构师或开发人员,几乎都是初级外包人员。我们的人工程师协助过客户的外包人员做一个基于Python的λ演示测试之后,他们的外包人员开始自己使用SpringBoot借助λ技术对原来的应用进行重构上云,然而进行到一定阶段时发现此技术需要很专业的技术人员才能够完全掌握,最后不得不放弃λ使用,回归到EC2部署方式。以下是做过一定删减的客户业务架构设计图:
业务架构图2
<强> 1)业务及人员
这种新技术是要求开发人员必须具备一定微服务的能力,能够应用进行拆分,并能够通过业务代码解决新技术存在一些缺点,还要求开发人员对原来的业务逻辑完全掌握。在新技术并不完善的情况下,并不是所有业务场景都合适重构为Serverless服务。此客户情况如下:
-
<李>开发人员与架构师对微服务掌握程度并不够李
<李>对要进行拆分的业务逻辑只是表面上的理解
<李>开发人员的代码能力并不高李
<李>客户的业务属于重型且持续交易电商平台李
<李>客户的测试流程并不完善
超时报错日志图3
<强> 2)技术选型:
在进行技术选型时,必须有一到两个人员对某一技术有一定掌握,前期进行大量测试与预研,充分掌握此技术缺点与优化.Lambda技术出现并不长,必然存在一些不完善,这样就要求开发人员能够对这些不完善有所掌握,并能够通过其他技术手段解决λ存在的缺陷,以满足业务持续服务的要求。
<强> 1。冷启动时间
<强> 2。开发语言是否合适
<强> 3。λ的请求并发与内存配置容量上限
<强> 4。AWS各个服务超时时间
<强> 5。在λ内存达到上限后,重启的问题
<强> 6。使用λ预热方案能否满足未来业务扩展
<强> 7。微服务化后,能否集成CI/CD功能
<>强实践总结:
用户在经历以上使用体验后,慢慢知道有些业务还要具备一定能力后,才能够去尝试,而不是急于求成,需要听更多专业人员的建议,一步一个脚印完成业务迁移,先从简单再到复杂,先从Rehost再到重构,如果要重构必须经过大量验证测试。以下是经历过此案例后一些建议:
<强> 1。λ合适在轻量级业务场景
<强> 2。做足冷启时间评估与测试
<强> 3。能够更细粒度拆分业务,以函数方式写业务
<强> 4。掌握并测试AWS各个服务的限制(例如:API网关的超时20秒,Lamdba的内存上限3 gb等)
<强> 5。选择更轻量开发语言(例如:Nodejs/Python等),尽量减少部署包的大小
<强> 6。非常熟练自己的业务
<强> 7。具备高级以上开发工程师
<强> 8。使用完善的监控,不断优化函数
重构是迁移当中最高级且最复杂的方式,最好有专业人员进行协助与指导,避免重复的成本浪费。建议如果客户的业务确实需要进行重构,请必须经过大量的功能与性能测试验证。(此文章若有错误,请指正,谢谢!)
