本文是 serverless 入门与实践 的第35篇
学习<华为 Serverless 核心技术与实践>, 计划: 1篇前言 + 10篇/章 + 1篇总结
Serverless平台与翻译服务
翻译服务架构技术选型
架构技术选型影响因素:
- 业务特点
- 团队特点
- 技术特点
- 总体成本
业务特点
翻译服务业务灵活，功能变化快:
- 语种变化，源语种和需要翻译的目标语种会随着服务商的不同和时间的推移发生变化。
- 翻译服务商的变化，不断有新的翻译服务商入驻。
- 翻译素材变化，随着开发者翻译需求的多样化，翻译服务商提供的翻译素材类型也会不断发生变化。
- 营销策略变化，例如定价调整、新增定向折扣等。
翻译服务不同角色之间的事件交互非常多:
- 开发者选择翻译服务商并在线支付成功之后，生成订单支付成功事件。该事件会触发系统自动创建翻译任务，通过互动中心向下单的翻译服务商发送订单支付成功通知消息。
- 翻译服务商完成稿件翻译上传之后，生成稿件翻译完成通知事件。该事件会触发三个子流程执行：系统更新翻译任务进度、系统更新订单状态及通过互动中心向开发者发送回稿通知消息。
团队特点
如果采用传统的技术构建翻译服务，无论后端是采用SpringMVC框架，还是使用当前比较流行的微服务架构，都会面临如下挑战:
- 服务端技术学习成本高，服务端涉及的框架技术比较多，比较常用的包括负载均衡器ELB/NGINX、Spring框架、分布式服务框架、关系型数据库服务、对象存储服务、Web服务器、ORM框架等。这些框架种类繁多、功能丰富、使用灵活，要想熟练使用这些框架需要较长时间积累开发经验。
- 多套服务端环境的维护成本高，翻译服务需要搭建服务端的开发联调环境、集成测试环境、灰度环境和生产环境，这些环境的维护成本比较高，需要专门的环境维护人员才能保障环境的可用性。
- 系统的可靠性保障低，业务存在高峰和低谷，以及限时营销活动等，系统需要能够应对突发或周期性的流量高峰，同时要避免资源闲置，提升资源使用率。构建一个能够灵活应对流量高峰的系统，团队需要有丰富的大促流量应对经验，系统架构具有良好的弹性，对于中小型业务团队，由于缺乏经验丰富的架构师，往往很难应对这些技术挑战。
- 架构的平滑演进，系统上线初期，入驻的翻译服务商有限，开发者创建的订单不多，通常单库单表就能支撑。随着业务的发展及交易量的增加，业务需要通过分库分表/读写分离等技术来解决性能和容量问题。每次大的技术架构变更，可能会涉及现网数据割接、业务兼容性等，其成本很高。因此，构建一个具有平滑扩容能力的架构非常重要，这涉及数据层和业务层的平滑扩容，需要对相关技术框架有非常深入的了解。
技术需求
前端Portal主要是由Web开发的:
- 前后端分离，前端只负责数据的加工和界面展示，不负责业务逻辑处理。可以采用Angular.js或Vue.js框架开发，部署方式灵活，不强依赖Web服务器。
- 传统的单体架构，前端界面和后端的业务逻辑可以在同一个Web工程中开发，部署在同一个Web服务中运行，如Tomcat。
考虑到架构的先进性和扩展性，服务端整体上采用分布式技术来构建:
- 后台业务逻辑，使用微服务或云函数进行开发。
- 数据存储、订单等关系型数据，使用支持关系型数据存储的云数据服务。
- 翻译素材等文件存储，考虑到成本、可靠性和性能等因素，使用对象存储服务进行存储。
- 事件触发和消息通知，可以基于传统的分布式消息队列（简称DMQ），事件总线或函数触发器实现事件的订阅通知等功能。
成本需求
翻译服务研发成本构成
