项目开发方案评选

背景和需求

  • 项目背景
    • 智能门锁猫眼项目, 需要支持远程与手机端音视频对讲.
    • 需要支持主流手机, Android 和 iOS. 最好也支持微信小程序.
    • 主要用户范围在中国, 但也需要考虑外国用户.
  • 项目需求
    • 预算有限, 主要部分须自研.
    • 终端产品的软硬件开发: 成熟的嵌入式linux方案, 掠过不表.
    • 手机端: 需要一个低成本方案的APP开发方案, 并便于后期的维护和升级.
    • 云端: 自主进行业务端的开发, 核心数据的收集, 迁移和维护. 为以后可能的增值服务做准备.
    • 云端非常重要但希望外包的: 灾备, 网络安全, 服务器运维.

Web 开发技术的概览和评估

Web 开发者学习路线图

JavaScript 框架

大前端开发

  • 大多数中小企业的痛点: 终端展示问题.
    • 随着移动端互联网的高速发展, 手机作为用户展示终端的需求居高不下.
    • 于是, 直接面临着需要用三种不同的技术去实现同一个需求的尴尬局面: 网页端, 安卓端和苹果端.
    • 大前端的概念就是利用web前端技术, 进行跨平台开发, 实现一次开发, 多平台发布. 减少开发成本和维护成本.
    • 这不仅仅是一个技术问题, 更是一个商务问题. 只要低成本方案的用户体验较好, 就会有爆发式的需求涌现出来.
  • 跨平台开发框架

后端技术

  • 云服务模型:

    • IaaS: Infrastructure as a Service. 基础设施即服务
      • 云服务商仅提供硬件. 包括服务器, 网络和存储.
      • 服务对象需要管理所有层面的软件安装, 开发和维护工作.
      • 云服务商: AWS, 阿里云 等等.
    • PaaS: Platform as a Service. 平台即服务
      • PaaS = IaaS + 部署 + 管理 + 扩展.
      • 云服务商额外提供可扩展的操作系统和数据库方案.
      • 这样相当于有了一个基本的软件开发平台.
      • 譬如 AWS Elastic Beanstalk.
      • 平台能提供的是一套标准的工作环境和接口, 服务对象按照标准进行接入.
      • 平台的概念是多层次的. 譬如:
        • Linux系统是软件开发者的一个工作平台
        • 淘宝对卖家而言是一个销售平台
        • 物联网云平台, 则提供了 IoT设备的接入, 数据收集和展示, 以及管理等功能
    • SaaS: Software as a Service. 软件即服务
      • 更传统的含义是: 软件即产品, 产品即服务.
      • 最终用户购买某一款软件产品, 并使用其中的功能获得服务.
      • 或者最终用户免费获得软件, 按包月/包年/广告的方式获得服务.
    • CaaS: Containers as a Service. 容器即服务
      • 容器是一种技术, 使用者是组织架构内部的软件开发人员.
      • 商务角度而言是一种工具, 不存在服务一说.
    • BaaS: Backend as a Service. 后端即服务
      • BAAS = PAAS + 构建后端特性
      • 云服务商提供自动化后端开发和维护云基础设施的平台.
      • 服务接口是组织结构外部的前端开发人员. 相当于将服务器运行和维护工作外包.
    • FaaS: Function as a Service. 功能即服务
      • 云服务商管理整个应用程序和所需的软硬件平台.
      • 服务对象专注于功能的实现和数据的管理(前端和业务相关的后端).
    • 微服务:
      • 核心是服务治理, 而服务治理的关键是服务划分.
      • 故微服务架构的本质就是对码农的分化和治理.
      • 依托的技术是 CaaS, 即容器技术的成熟.
      • 因而微服务的对象是组织内部, 商务角度而言不是一种服务.
    • 无服务:
      • 核心是使用 BaaS 的技术, 为服务对象提供功能, 即FaaS.
      • 所谓的无服务器, 是指对服务对象而言, 整个服务器的配置管理和运维都被隐藏起来了.
      • 注意: 由于需求端的复杂性和多样性, 云服务商是没办法像水电煤公司一样来提供标准化服务的.
      • 潜在的问题:
        • 所需的服务需要是无状态的, 或者对时效性不那么敏感. (需要利用存储服务来保存和读取状态)
        • 难以复制的开发环境, 意味着很难进行本地测试.
        • 冷启动时的响应时间.
        • 标准不统一, 容易出现厂商锁定. (即迁移成本可能非常高)
        • 真正上线使用之前, 很难评估使用成本.
  • 参考资料:

个人的认知和选择:

  • 互联网的生命周期依旧处于发展期, 才会有各种各样的新概念新名词层出不求.
    • 存在于二元对立的世界, 对于所有的观念, 必须问清楚”主体”是谁, “客体”是谁, 再看两者间的”关系”.
    • 只有清楚的知道”我是谁”, 才能知道自己的切实需求, 才不会被概念和名词所迷惑.
  • 面向过程和面向对象的两种思维, 体现的是站位不同导致的思维不同.
    • 面向过程: 是结果导向的, 是用来解决具体问题的. 越是面临具体问题的人, 越倾向于面向过程的思路.
    • 譬如UI界面中的事件驱动/消息驱动机制, FaaS概念的提出.
    • 面向对象: 是对事物的抽象能力, 可用来归纳总结已有的认知, 还便于创世.
    • 譬如科学界各种各样的分类法; 软件框架和开发模式的总结; 女娲造人; 神就照着自己的形像造男造女.
  • 对于物联网, 吹牛的人不少, 做实事的也不少. 但都没跟上互联网的思维和脚步:
    • 从理念层面, 需要提出: TaaS: Things as a Service.
    • 从技术层面, 需要大幅度降低嵌入式设备开发的难度和入网成本, 将嵌入式设备抽象为大前端的一个API, 函数或功能.
  • 根据项目所处的环境, 考虑到人员/资金/开发周期等综合因素, 初步的选择:
    • 评估 uni-app 在手机端双向语音视频的性能, 如果可接受就选用 uni-app 进行跨端开发.
    • 无服务技术的概念和方向没有问题, 但尚有待发展完善, 需要积极测试跟进.
    • 保守起见, 此项目暂不予考虑无服务技术, 故而采用 PaaS 方案.
    • 后端开发从零开始, 无任何负担. 综合性能, 学习曲线, 向后兼容性, 招人的难易程度等, 现阶段决定选用TypeScript进行后端开发.
    • 如果有潜在的高性能需求, App端可选用 Flutter, 后端可选用RustGolang.

原创于 DRA&PHO