一个人也能支撑起的项目是怎样的架构

简介: 云托管真的是开发者的福音!!!不仅简化了小程序API的接入,还省了买服务器的钱。像灰度发布、监控实例、服务器规格调整这些头疼的事儿,统统都不用费心。

前言

因为种种原因,《软件开发人员从0到1实现物联网项目》这个项目的进度停滞了将近一个月。

鉴于该项目的前期开发和后期的维护就我一人,为避免开发效率低下和后期维护中的潜在问题。我针对项目架构进行了初步的思考,从开发模式到后期维护进行了全面的梳理。基于这些思考,最后整理出了一份简单的技术架构图。有什么不足之处还请各位大佬不吝赐教,欢迎提出宝贵的意见和建议。

单体应用足矣

前两年的市场绝对是微服务的天下,开发个什么系统,动不动就是微服务,几乎已经成为每个项目的标配。

在我看来,微服务只适合业务规模大、团队规模庞大的项目。主要是一个大项目在单体应用下确实会存在很多问题,就像2007年的淘宝网一样:

整个淘宝网是一个几百兆字节的WAR包,大大小小的功能模块超过200个。几百人维护一个WAR包就会带来很多问题:

  1. 项目团队间协同成本太高,业务响应越来越慢。
  2. 应用复杂度超出负载认知,没有一个人能完全清除每一个功能和业务流程。
  3. 数据库连接能力很难扩展,数据库的连接数量会随着应用实例的增加而捉襟见肘。
  4. 错误难于隔离,任何一个小的问题都会造成整个实例崩溃。
  5. 应用扩展成本高,通常出现业务瓶颈时都是某几个功能模块影响的,但是需要增加一个完整的应用实例,带来的是额外的资源消耗。

每一次的功能升级都要牵一发而动全身,这种情况下就不得不拆分系统。

自助棋牌室系统或者说是无人看守门店系统,一个小小的项目,功能并不多。所以,单体架构,足矣。否则,带来的只有繁琐的开发部署流程以及高昂的运维成本。

摒弃传统的小程序对接

本项目的用户终端主要包含小程序和后台管理Web端。其中小程序服务于用户和商家,Web端则为商家和后期维护人员提供管理工作。

App一开始就没在考虑范围。( App 下载门槛高,打开率低)

在小程序与后端服务的交互方式,我决定使用云调用,主要是为了简化代码开发流程和规避不必要的风险。

以支付功能为例,使用传统的对接方式,需要涉及复杂的步骤。如下图

虽然有很多SDK可以简化和小程序的对接流程,但还是消除不了相关的工作和潜在的风险。毕竟,每增加一个处理环节,都可能会增加潜在的风险。

在小程序中直接调用支付宝的后端开放接口,不需要关注服务端的相关配置,极大的减小了接入的流程,进一步降低了小程序的开发门槛。

后期的维护投入

虽说是单体应用,但也是可以具备高可用、高并发能力的。除了程序自身的性能外,还需引入很多机制来辅助。例如实施负载均衡、实现数据库的读写分离以及确保应用实例的弹性扩缩容等。

但是,这些机制的引入会消耗自身的一些精力,尤其是后期复杂的维护工作。鉴于该系统后期的维护就我一人,为了降低维护成本果断上“云”。

上真正的“云”:云托管

在了解小程序开发期间,我发现了云托管这个强大的产品。如果说云开发是专为小程序开发量身打造的,那在我看来,云托管可以算是真正的“云”了。

简单来讲,云托管就是:把你的程序交给云管理,免去人工运维

0服务器免运维

云托管的免运维具体体现在以下几点:

  • 自带功能:云托管自带监控告警、日志服务等后期运维所需功能。
    (实现哪个功能不需要工作量?)
  • 自动扩缩容:根据流量多少和自身承载消耗动态的进行扩缩容,从而保证服务高可用、高稳定,也无需为闲置资源付费。
    (既不用自己管理计算节点又可以避免额外的资源成本,而且,高可用和高并发是不是解决了?)
  • DevOps自动化: 提供流水线能力,可以实现从代码仓库到服务发布的全自动流程。还提供灰度发布、版本回滚这样的部署能力。
    (不用自己打包部署或者自己搭建DevOps环境)

就是说,单单这三点能为我省去多少工作量。如果应用部署到云服务器上,哪一个工作量不够我喝上一壶?我还用担心半夜的服务监控告警吗?

当然,云托管不只是对应用程序的托管,还提供了Serverless形态的Mysql,也可自动扩缩容,避免产生瓶颈。
(又省了Mysql的运维工作)

不过,这都不是重点,重点是云托管还提供了免费的CDN和DDoS防护。

免费的CDN和DDoS防护

CDN和DDoS防护都非常重要,我对此深有体会。在我的职业生涯中被CDN和DDoS上过一课。一次是在新产品上线后,遭到竞争对手的恶意攻击引起的系统崩溃。另一次是因为抢购功能的上线,带宽被刷爆,导致页面加载不出来流失了大量用户。

得亏老板有钱,一个月几万元的DDoS的高防套餐说买就买。像我这样的情况或者一些初创公司是承担不起的。

但是,把程序交给云托管就不一样了,借助云厂商的资源,DDoS攻击者打不起、也打不挂。重要的是开发者不用为此付费。

这么看来,云托管的性价比是非常高的。

技术架构

项目依托云托管,所以整体的复杂度会小很多。

除了必要的MySQL外,只需引入Redis,主要是要做一个无状态服务,以便横向扩展。

在物联网方面,还是考虑接入物联网开发平台。真得会减少很多工作量和后期的维护,而且像国内的这几个云厂商都是有公共免费的额度可以使用,所以在开发阶段不会投入成本。

下面是基于云托管的技术架构图

小结

云托管真的是开发者的福音!!!不仅简化了小程序API的接入,还省了买服务器的钱。像灰度发布、监控实例、服务器规格调整这些头疼的事儿,统统都不用费心。还有那种一个月要几万块才能搞定的DDoS防护,不用理会。美哉!

(不是广告)

准备进入开发阶段...

相关实践学习
Serverless极速搭建Hexo博客
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
相关文章
|
1月前
|
前端开发 JavaScript 测试技术
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
102 2
|
20天前
|
前端开发 JavaScript 测试技术
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
在 Android 开发中,选择合适的架构模式对于构建中大型项目至关重要。常见的架构模式有 MVVM、MVP、MVI、Clean Architecture 和 Flux/Redux。每种模式都有其优缺点和适用场景,例如 MVVM 适用于复杂 UI 状态和频繁更新,而 Clean Architecture 适合大型项目和多平台开发。选择合适的架构应考虑项目需求、团队熟悉度和可维护性。
48 6
|
21天前
|
存储 前端开发 数据可视化
在实际项目中,如何选择使用 Flux 架构或传统的 MVC 架构
在实际项目中选择使用Flux架构或传统MVC架构时,需考虑项目复杂度、团队熟悉度和性能需求。Flux适合大型、高并发应用,MVC则适用于中小型、逻辑简单的项目。
|
30天前
|
前端开发 JavaScript 测试技术
Android适合构建中大型项目的架构模式全面对比
Android适合构建中大型项目的架构模式全面对比
46 2
|
1月前
|
存储 分布式计算 Hadoop
Hadoop-33 HBase 初识简介 项目简介 整体架构 HMaster HRegionServer Region
Hadoop-33 HBase 初识简介 项目简介 整体架构 HMaster HRegionServer Region
53 2
|
2月前
|
负载均衡 数据库 开发工具
|
1月前
|
缓存 前端开发 JavaScript
前端架构思考:代码复用带来的隐形耦合,可能让大模型造轮子是更好的选择-从 CDN 依赖包被删导致个站打不开到数年前因11 行代码导致上千项目崩溃谈谈npm黑洞 - 统计下你的项目有多少个依赖吧!
最近,我的个人网站因免费CDN上的Vue.js包路径变更导致无法访问,引发了我对前端依赖管理的深刻反思。文章探讨了NPM依赖陷阱、开源库所有权与维护压力、NPM生态问题,并提出减少不必要的依赖、重视模块设计等建议,以提升前端项目的稳定性和可控性。通过“left_pad”事件及个人经历,强调了依赖管理的重要性和让大模型代替人造轮子的潜在收益
|
1月前
|
前端开发 JavaScript 测试技术
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
40 0
|
1月前
|
存储 消息中间件 前端开发
.NET常见的几种项目架构模式,你知道几种?
.NET常见的几种项目架构模式,你知道几种?
|
1月前
|
存储 Kubernetes Go
Go语言项目组织架构
Go语言项目组织架构
下一篇
无影云桌面