文章提出了基于微服务架构的团队管理模式，并通过需求调研识别出开发者在Web服务开发中的痛点，如学习成本高、部署复杂和计费模式不透明。为解决这些问题，项目计划设计一个以简便和易用为中心的FaaS平台，提供在线编辑、一键部署等功能，降低开发门槛。竞争对手包括华为云、腾讯云和阿里云的函数服务，但这些平台存在应用复杂、计费方式繁琐等问题。项目旨在服务个人开发者，通过校内课程推广或演示示例来吸引用户，预期用户量约为100人。
一、团队结构与管理模式
“设计系统的架构受制于产生这些设计的组织的沟通结构。”
——M. Conway
https://en.wikipedia.org/wiki/Conway%27s_law
我们的项目计划采用微服务架构，将模块根据功能聚合，模块之间分离
所以我们的团队会由多个小组构成。
暂时无法在飞书文档外展示此内容
同时，考虑到团队中对开发的经验水平不同，以及团队成员的主要语言不相同。
开发小组会采用老带新的形式，并在小组内采用统一的开发语言。
而小组之间依靠IDL约定接口通信，彼此之间模块内透明。
二、需求调研和分析
针对当前开发者Web服务的开发状况，我们针对北航计算机学院、软件学院的同学进行了问卷调查。
调查将目标用户分为两种类型
- 有开发Web服务经验和需求的开发者
- 没有Web开发经历但是希望尝试的开发者
发现传统情况下，开发Web服务存在着以下几个痛点
- 开发框架具有学习成本
- Web服务不进行部署难以获得正反馈激励，但部署服务需要耗费一定程度的心智
- 传统云计算厂商提供的计费模式存在着浪费情况
由此，我们确立了我们的选题和着力方向。
三、NABCD
3.1 Need
随着网络在人们日常生活中的地位日益重要，人们对便捷网络服务的需求在不断增长并且速度极快。部署网络应用，需要完善的基础设施的支持，服务部署和运维的复杂性和高成本很大程度上限制了创意的实现。所以对低运维负担，部署便利的网络应用开发模式的需求也越来越大。
3.2 Approach
我们计划设计实现一个部署便捷和简单的FaaS平台，以简便和易用为主要着力点，降低开发者部署网络应用的门槛。
3.3 Benefit
通过在线编辑、一键部署、弹性扩容、可视化监控、灰度迭代等功能，将传统部署中对于简单开发意义不大但是繁琐的部分向开发者透明化，降低开发门槛，促进网络应用的繁荣发展。
3.4 Competition
针对这一应用场景，竞品主要有华为云、腾讯云、阿里云的函数服务平台。
他们都是成熟的云计算服务提供商，拥有着坚实的技术基础和完善的服务，这是他们的优势。
但是同时他们对目标用户而言也存在着劣势。
- 应用种类过于繁杂，不够清晰易用，用户难以找到所需的服务
- 计费方式复杂，其计费方式有很高的自由度，但是带来的影响就是计费方式太过复杂，而且打包出售，难以实现成本计算且同样面临着资源无法完全利用的问题。
- 划分粒度较粗，往往还是以项目为单位，无法很好地屏蔽框架细节以及探查函数信息。
3.5 Deliver
目前分发方式有两种：
首选：通过校内程序设计相关课程组结合课程内容进行推广，并尝试将计算资源迁至校内。
备选：利用平台实现一些具有普适功能的demo，通过视频网站、论坛等展示使用场景，通过平台的产品对平台进行宣传推广。
四、选题意义
Function as a Service架构，是一种先进的服务组织架构。
我们希望借助软件工程课这一个机会，对这一种服务组织架构进行一些实践。
实际上于我个人看来，这一架构的意义并不只在于面向独立开发者的简单易用。
其更重要的价值在于大型项目中的提效、分立与解耦，面向个人开发者的简单易用实际上只是提效的一个部分。
容器级别的虚拟化降低了虚拟环境的开销，使轻量的服务环境隔离变得可能。自此微服务可以划分为更细的粒度，提高了服务可靠性、治理能力和容灾能力。
这一产品的企业市场已经几乎被瓜分殆尽，大企业往往会选择自建FaaS平台，甚至针对不同的细分领域会分别建立，而小企业需要追求稳定和完善的服务，往往会选择大型云计算厂商提供的服务。
但面向个人开发者的FaaS平台仍然具有一定的市场，我们希望能抓住个人开发者的痛点，在这一领域尽我们的努力，完成一次“足够好”的实践。
五、发布与预期
软件会以Web形式发布
Alpha阶段会于公网发布，Beta阶段开始寻求校内合作，如果成功则将迁移进入校内部署，否则保持公网发布，并申请域名服务。
预期用户量100人左右，峰值运行函数0.5个每人
2057
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
