微服务springCloud深入项目技术架构

现在说到微服务，IT界已经耳熟能详；我现在看到一个现象，这些项目该不该用微服务，或者根本不知道怎么使用的情况下，生搬硬套也要使用，最后不仅开发时间增加、维护费用增加、设备使用增加，带来的效果微乎其微。

 

    我接手的已经完成的微服务项目也有10多个，能接受的也就2、3个项目而已；最次的是数据不分离，数据映射层耦合，各种表联查，微服务之间相互调用，调用链乱成一团。

    稍微好些的是数据层分离，但职能划分不清，用户、组织、角色、功能、业务逻辑也是乱成一团，服务之间相互调用；其实还不如单体架构分好模块。

    再好些的知道把用户中心、规则、工作流剥离出来，形成服务能力，但业务服务调用链还是一团乱麻。

     在国内，大部分项目开始的业务需求、业务架构是不清晰的，并且需求变动频繁。

     那么使用微服务构建时，能不能从技术上找到解决方式？

     根据上述项目的痛点，以及一些项目具体的实施经验，融合中台的一些思想，构建具体的微服务架构。【其实中台不过是各个服务能力的汇总而已，当然，基础服务能力不可少,CI/CD,DevOps对微服务的帮助就不细说了，这也都属于中台的范畴，包括云服务（其实小企业可以使用公有云即可）。技术中台与业务中台，数据中台也是，提供各种类型及业务方的数据沉淀、数据API，使企业数据交互的成本降到最低。】

首先，构建基础服务能力：上述也说了，基础服务的不可或缺性。我称基础服务能力是所有服务的基础，是服务运行的环境及检查站、快速迭代的根本。不然那么多服务，靠手动去维护，并发量高了靠手动去加节点，不现实。【当然了，开始阶段可以不做这些，直接用阿里或华为成熟的产品就OK了】

  

其次，构建原子服务群：原子服务在我的理解是自成服务能力的，最小颗粒度的服务。

1. 用户中心：提供用户、组织、角色、功能及授权，可以根据企业性质细分，互联网忽略（有IDMapping与用户分级即可）

2. 规则引擎

3. 统一的文件存取服务

4. 作业调度

5. 服务编排（包括算法、服务、数据等，从场景角度编排顺序、并发、数据合并等）

等等

其实上述的原子服务群也就相当于技术中台提供的服务能力。其实每个项目积累一个技术服务能力或业务服务能力，那么公司的中台自然而然就从无到有。

    根据上述，首先把这些技术的、业务的，可以提供公共服务能力的服务抽取出来，不管做成啥样，起码先抽出来，后续你有时间可以直接扩展、优化，而不影响其他服务。

     在实施一些项目中，代码质量也一直成为问题，毕竟开发人员的水平不统一，所以就忙里挤时间封装了持久层、myibatis/mongodb以及缓存redis、自动化生成工具模板（从mapper，service、controller、api、feign）一套微服务生成模板，以及可以直接使用的Excel导入导出工具，包含一些线程的工具包。

上述的模板等请参考：待续，可加QQ：793708083

数据库模型设计，一般是图模型方式；如（项目则有项目基础表模型，考虑子项目及分期，需要有项目关系表模型，考虑项目关键指标是动态，不确定字段；则新建指标表模型，项目或类型或组织的映射表模型。而根据上述，项目及附属表模型为项目库模型，指标及附属为指标库模型。）那么相应模型的职能清晰，耦合性低，扩展性强。

 

根据微服务化设计思路及多种项目架构的沉淀及总结，构建集团财运体系的业务及技术服务体系。