关于技术架构的思考

技术选型实则是取舍的艺术

这句话是我偶然在一篇技术架构方面的文章上看到的,每当我需要给新项目进行技术选型,决定技术架构时,一直坚信的。

当我们做技术选型时,需要考虑的东西非常多。比如,用关系型数据库还是非关系型数据库,MySQL还是PGsql,要不要用Redis,需不需要支持分布式文件存储,模块化还是耦合,用什么协议与第三方系统交互,用golang还是java,golang的话用gin还是kratos,微服务还是单体,系统预计有多大并发。

这些技术都没有优劣之分,我们需要根据实际的场景选择最合适的方案。记住,可以有远见,但不要过度设计。过度的设计对于系统和开发人员都是一种负担。我见过很多小团队,无脑上微服务,实际上微服务有它的代价,而小团队没有得到微服务的好处,反而为了微服务架构付出了不必要的代价。

先理解需求

在技术选型上,我最常犯的错就是对于需求的理解不够,常常因为一些细节问题推翻技术架构设计的某一个局部,虽不至于整体推翻,但是也做了很多弯路。在选择数据库的时候,要考虑实际场景,比如,读多写少还是写多读少,数据量有多大,需求会不会频繁变更,变更对于数据结构的影响大吗。一般我会用MongoDB和MySQL处理常规场景。我说的常规场景是指,当项目按照迭代的方式进行,后期大概率会发生不小的调整和变更,数据结构不是特别复杂,数据量单表相对较大等等情况下,我会选择MongoDB,比如文档类项目、社交项目、企业官网等。当数据量不是特别大,数据关系比较传统关系比较确定且复杂等情况下会选择MySQL。其实现在两个数据库在大部分场景下都可以互相替代,在选择的时候还可以考虑团队的偏向、历史技术沉淀等因素。我认为MySQL不适合处理海量数据的存储,单表上亿简直是灾难。MySQL的分库分表也有它的缺陷存在,在需求对整体数据进行分析处理的时候,即时分库分表了,效率也非常低下,同时在使用的时候复杂度也比较高。在技术选型的时候,我会尽量让开发人员能够写简单的代码,不用因为选型给业务思考带来更多的负担。

有一些和第三方对接的场景,要去调研清楚,第三方能够提供什么数据,支持什么技术栈。和第三方之间是通过推还是拉的方式拿数据,是全量还是增量,增量同步的时候多久做一次数据校验。支持什么协议对接,消息队列还是Restful或者别的协议。我曾经对接过一个GPT服务,一开始设计的是会有一个数据清洗加推送的服务,把本服务数据清洗过后推送给他们。后面一聊发现,他们需要自动生成sql语句,连我们的数据库执行查询语句。就把对接方式改成了直连中间库。中间浪费了测试数据清洗和数据推送技术可行性的时间。应该在和GPT方聊完再去确定技术架构的。

一些取舍

沉淀

接的项目多了,就可以沉淀下来一些规范。现在部门也沉淀出了一套处理不同类型项目的技术选型规范,可以复制粘贴基础库半小时内搭好一个框架。

除了框架搭建和技术选型以外,我们还沉淀了CICD规范、代码规范、依据DDD的分层规范、Git管理规范、研发流程规范等等各个维度的大大小小十几个规范。

MySQL还是MOngoDB

现在MongoDB用的多,一般不是很复杂的业务都直接上MongoDB了,主要是简单灵活,开发快。

时序数据库

有时候会有一些IOT设备的实时数据推送,一般会把这类数据存到TDengine,还挺好用的,可以用
SQL的语法处理数据,不用搭建一整套的大数据脚手架工具,就是生态不够完整,希望越来越好吧。

搜索

搜索要求比较高的时候会上Elasticsearch(以下简称ES),不过这个东西太吃资源了。有时候要求不高的时候会用MongoDB的Text类型索引,也支持搜索,不过只能支持完整单词匹配,分词做的不是很好,毕竟不是专门做搜索的。MongoDB好就好在不用多加一个第三方组件,然后也没有ES那么吃资源,内存毕竟挺贵的。虽然MongoDB也基于内存做查询优化的,但是相比于ES就好多了。

动态属性

曾经给IT部门设计过一个资产管理系统,他们要求资产类型和资产的属性都是可以扩展和自定义的。于是用了MongoDB去实现。其实需求就是一个EAV模型 Entity-Attribute-Value(实体、属性、值),使用MongoDB实现EAV会更加方便灵活,因为MongoDB天然支持JSON格式数据的存储。具体不再赘述了,有空再另一篇文章记录一下当时怎么设计的。简单讲就是下面这种结构,这是一个人员的实体,固定属性是Name,还有sex、region、QQ等可以让用户自定义的扩展属性。
关于技术架构的思考_第1张图片

golang的服务开发框架选择

golang在业界并没有一个统一的标准,不像java,基本上被Spring一统天下了。我司用的比较多的分别是Gin和Kratos,我一般用Kratos,可以做单体,也方便扩展微服务。Kratos这套是完整的解决方案,有API生成,依赖注入,限流,错误处理等等部件。在做一些组件上的技术选型的时候,一般会花更多的心思。比如选择限流方案,需要考虑限流的策略算法,资源池型和令牌桶型;需要考虑社区活跃度,有多少人用,除了问题官方会不会立马解答,要看看issue库里面坑多不多;另外还要考虑对代码侵入性高不高,能不能在中间件层无侵入注入。

服务监控和告警

没什么特殊要求的话, 整个部门共用一套K8s监控集群,内部安装了Prometheus+Grafana+alertmanager做监控、看板和告警。可以满足集群内部和外部的监控需求。

命名规范

这里主要是MongoDB的命名规范,下划线、中划线、首字母大写驼峰、首字符小写驼峰,这些选择感觉很多厂的选择都各不相同。我觉得只要部门内所有的系统保持一致就行了,具体用哪种反而不重要。我会去MongoDB的官方文档中,看他们CRUD的示例的集合和字段是用哪种风格,然后决定用什么,把这套规范推广至整个部门,让所有项目保持一致。只要一致,就可以减少一些成本。

代码检查

一般会利用Git的Pre-Commit做一个代码提交前的自动检查,在代码提交前,自动调用golangci-lint插件检查代码风格。

Git管理

GIt管理一般有GItFlow和GIthub Flow。少于5个开发的项目用GIthub Flow,就一个Master分支,用MR进行合并代码。多于5人用GIthub Flow,多了一些develop或者版本分支,代码合入到这些分支,分支开发完了才合入到master。提MR之前要用git rebase保证提交历史是线性的。

你可能感兴趣的:(思考,架构)