关于TOC项目架构的一些思考2023.11.29

公司之前有一个小程序+管理系统的项目，专门给其他公司使用的，项目采用的是单体架构，初期为了快速搭建，购买了企业级的快速开发平台BladeX，以BladeX为基础进行搭建的，而且小程序和管理系统的接口都写在同一个项目中。

公司可能感觉项目收益慢，准备抽出原有项目的核心业务，做成一个TOC项目，开放给所有用户使用，但是也会保留给其他公司层面定制化的操作，然后这几天就要开始架构这个TOC项目了。因为TOC项目自己也没做过，也没架构过项目，但是也思考了好几天，有一些想法记录一下，对自己也是一种提高：

1.首先是单体和微服务的选择

公司需要的是快速上线，积累用户，再进行二期三期开发，实现盈利。但是这个项目搭建完成后，不知道会有多少用户，还要看销售推销的情况，所有一切都是未知。

考虑到单体架构构建、开发、调试和部署成本会很小，觉得目前阶段单体项目最合适，相应的单体架构也有缺点，可扩展性和故障隔离等等，但对于目前阶段来说，利大于弊。

因为是TOC项目，也考虑过微服务架构，虽然可能说不出来为什么，但是感觉TOC用微服务就没错（还是知道的太少了），微服务的扩展性、独立部署、集群部署等等方面非常便捷。但是目前看了一下一期的原型，能抽出的服务不多，如果要用微服务架构的话，开发复杂性，数据一致性以及运维难度等等都会成指数增长，目前我公司就3个后端，而且服务的部署必须要有CICD的支持，否则部署一次会非常的麻烦，而且一个java服务基本三四百兆的内存，使用微服务架构一期也最少七八个服务，服务器的开销也要考虑的。

所以按我的想法，目前应该采用单体架构来构建这个项目，采用包隔离开发，如果上线后用户可观，根据包隔离抽离代码，封装成一个个服务，报错的地方写rpc调用，完成从单体到微服务的转变，并相应的要搭建CICD支持微服务架构的部署。

2.项目搭建的选型

因为公司买过BladeX，同事想用这个进行搭建这个TOC项目，我感觉不是最优的方式。

我也去了解了一下这个BladeX，这个平台解决的最大的用户痛点是可以让用户快速开发搭建一个微服务项目，里面集成了ELK、链路追踪、监控大屏、多租户权限、工作流等等功能，一应俱全，使用这个开发出来的项目应该是类似那种SaaS系统，我公司原有的项目虽然用的这个平台搭建的，但是这些功能一个也没用上，只用了里面的一些工具包和权限功能，感觉就是一种浪费，还增加的开发同学的学习成本，需要学习这个平台的API，提供的便利性有限。项目里大量使用了BladeX的工具类，如果要对这个项目重构的话，会很麻烦，耦合性太高，并且通用性很差

首先这个BladeX里面有很多东西这个项目是用不到的，比如权限、多租户以及微服务相关的东西，而且用BladeX来构建，需要导入对应的表，里面的字段是限制死的，少了可能就会报错，就拿user表来说，TOC的user表可能就个手机号加一些信息，BladeX自带的用户表里面除了这些信息还有租户id、部门id、角色id、密码等无用字段，所有感觉如果使用BladeX来构建会让这个TOC项目很臃肿，所有个人来说不建议用BladeX进行构建，无法享受BladeX带来各种优势，反而让项目中多了很多用不上的东西，虽然不用，但放在那也碍眼，影响项目整洁度，单体项目的构建也很方便，建一个空项目，工具类的话，Google、Apache、hutool三家的工具类基本已经很完善了，需要使用什么就配置什么，所有个人感觉使用BladeX来构建是弊大于利，更倾向于建一个空项目

后面可能会搭建TOC项目对应的管理系统，涉及到权限什么的，这时候我更推荐使用BladeX进行快速构建，然后这时候小程序和管理系统里面肯定有逻辑代码重复，这个时候应该转向微服务架构了，小程序和管理系统只是一个壳子，里面的逻辑从对应的服务中取，如果项目顺利的话，数据库可能成为瓶颈，后面建议拆分成不同服务，每个服务有各自的数据库，这样就可以解决数据库的瓶颈了

参考：一文搞懂微服务架构演进

以上就是我的一些思考，不保证对，但好在思考了，如有想法错误的地方欢迎指正