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