主要针对新的项目
1 - 开始不要着急搞微服务,分布式,无疑会加大开发成本,拖慢开发速度,除非团队有基础,水平很高.
2 - 可以按照微服务的架子进行项目开发管理,比如拆分出用户管理模块,设备模块,某某应用模块等等,url统一前缀,建立各自的service,utils,source等等,数据库根据业务区分前缀,便于后期拆分服务.
3 - 使用统一的时间库,json库
4 - 数据库存时间戳或utc时间,前端根据时区处理,解决时区问题
5 - 后端返回前端格式统一,一律用状态码进行提示,这样多语言就可以放在前端处理了,而不用两端同时处理
6 - 不要在controller中写业务逻辑,只进行参数验证,逻辑写在service里,便于重用
7 - 参数验证前后端要统一正则表达式,要单独建立一个utils,统一管理参数验证
8 - 一边开发,一边重构,一旦某段代码复制了3次就重构之前的代码
9 - 一个方法只做一件事,一个类只做一种事,一个服务只做一类事
10 - 使用lambok优化pojo类是个不错的选择
11 - 数据库表名统一以下划线方式,类,属性,方法用驼峰方式,常量全大写
12 - 统一处理异常,统一验证权限,不要放到各个接口中,使用aop
13 - 开发时,经常使用git分支,可以有效提高开发,运维和测试的工作效率
14 - 尽可能不要联调测试,可以用doker部署下,让测试人员连docker
15 - 写了service,心虚的那种,可以先在test中自己测试下,这样可以缩小问题的范围
16 - 不用太多注释,尽可能用合理的方法名说明要做什么事,保持代码简洁
17 - 代码没写完,下班了,一定写一个todo,可以减少第二天回忆的时间
18 - 如果用户多了,撑不住了,可以先考虑垂直扩展,毕竟用户多了也就有钱了,增加设备配置会省不少事
19 - 如果还撑不住,就搞个负载均衡,nacos?dubbo?nginx?如果流量削峰,rocketmq?
20 - 如果数据库扛不住了,先考虑把大的字段拆到别的表,还不行,就分库,分库,加配置也撑不住了,那就分表吧,水平拆分shardingphere,leaf...
21 - 这个时候就可以考虑拆分服务了,所有的业务应该都差不多清晰了,康威定律,按照公司的架构模式拆分估计也差不多了
22 - 这个时候可以使用springcloudalibaba那一套方案
23 - 逐渐演变成k8s + istio服务网格,数据库迁移到tidb
以上也是在开发过程中,查询资料,学习了解到的.
实际项目没有真的走到微服务那一步,也许以后会用到,记录一下,目前项目也只是增加了设备配置...