微服务的应⽤脚⼿架(上)——功能脚⼿架(技术)

灰太狼 2023-10-03 13:23 5阅读 0赞

——云基地 Samuel

###  ###

## Intro ##

⾯对微服务⽣态⽇新⽉异的技术更迭与复杂⽣态，作为企业开发，我们更加 迫切地希望能够获得⼀个包含不仅限于注册中⼼、配置中⼼、多⽅通信、web框 架、ORM、缓存、安全认证、⽇志、任务、消息、事务等等⼀系列技术点的⼀站 式微服务⽣态解决⽅案，相信在项⽬中，每逢到需求澄清环节后的技术选型环节， ⾯对⼀系列微服务⽣态技术，或多或少的开发者都有点意⻅分歧和碰撞，原因在于 每个经验丰富的研发都有⼀套⾃⼰的⽅法论和技术体系，选型的“内卷”便由此⽽ ⽣。那么，⾯对以上问题，我们企业该如何破局，为此，我们希望的是，⾯对以上 的⼀系列技术点，如果有⼀套完整的、标准化的选型那就好了，可是，如何统⼀技 术标准和技术选型呢？我们认为，需要在技术细节和技术实现上选择经受住成熟 的、⼤型的、结构复杂的项⽬验证过的技术⽅案来进⾏抽象和统⼀，所以，就像建 筑公司盖房⼦，我们做项⽬，最好也有⼀套标准化的、泛⽤的基础脚⼿架，来达到 企业内部项⽬技术的***作业施⼯统⼀化、全员技术标准化。***

###  ###

## 什么是技术标准化 ##

技术标准化是什么，很多技术⼈员都有⾃⼰的⼀套⽅法论，我们认为，在微 服务⽣态中，我们企业内部⾸先需要做到接⼝定义的标准化与研发模型的标准化， 那么什么是接⼝定义的标准化，什么⼜是研发模型的标准化呢？

*  **接口定义的标准化**

微服务中⼤部分服务都采⽤的是Http通信，因此，频繁交互的前后端 中，需要⼀套标准化的交互体系和逻辑才能做到较⼤限度地提升开发效率， 为此，我们在REST接⼝中，需要严格定义消息的请求体规则与返回体结构， ⽅便后端识别请求体与前端识别返回体，针对请求体的识别，我们可以在REST调⽤中，通过REST规范来进⾏约束，⽐如查询请求中，可以通过最为常 ⻅的GET请求来进⾏前后端交互，当然这是理想状态，我们不是所有的查询 请求⼊参都是⾮敏感信息，可能还会伴随⼀些较为敏感的交互信息进⾏⾮明 ⽂传输，例如加密信息和表单信息，那么我们仅通过简单的REST⽅式肯定不 会得到满⾜，那么我们会进⼀步将POST请求改造为⼀个“类GET请求”，就是 将明⽂参数和表单信息通过⼀次请求，不同⽅式提交，⽐如明⽂放 requestParam，表单放body，密⽂放header，通过⼀次POST请求，做到 进阶的交互式查询请求等。

那么，在企业中，以上的举例当然层出不穷，为此，我们需要做的就是 需要在企业内部定义⼀套属于⾃⼰的前后端交互规范，当然，包含且不限于 REST这⼀种，在员⼯⼊职时便进⾏统⼀的培训与相关的规约传导，以此，在 所有员⼯中⽤企业的约束达成标准化意⻅上的⼀致性。

*  **研发模型的标准化**

微服务⽣态中，企业⾯对⼀个个微服务项⽬中的⼀个个独⽴服务，少则 ⼏百，多则⼏千上万，⾯对如此多的个体微服务数量，我们肯定也是需要⼀ 个宏观上的标准化模型，明确代码的基础分层，对开发者起到⼀个最基本的 指导。

作为⼀个JAVA开发者，肯定都知道什么是***MVC***结构，可是这个结构在 微服务⽣态下⼜太抽象，所以，我们在这⾥⼜提出⼀个***AFCCS***结构，那么， 什么是***AFCCS***结构呢——A即**A**PI，F即**F**ACADE，C即**C**OMMON，C即 SDK-**C**LOUD，S即**S**DK。

***AFCCS***结构中，每个字⺟代表的分层都有各⾃专业的分⼯、严格的边界 和严谨的顺序。SDK层负责为三⽅系统和服务⾃身提供⼲净的标准的DTO对 象，⽤于外部交互；SDK-CLOUD包含SDK，提供微服务项⽬⾥服务间交互的 对象，⽤于系统内部交互；COMMON包含SD-CLOUD，提供单个服务中的 数据模型，⽤于和数据存储载体交互，包含RDS与⾮RDS，同时也可以⽤于中 间件数据的模型定义，是中⼼模块，向下承接数据储存的载体，向上输出 CRUD封装的VO对象；FACADE包含COMMON，是单个服务中的逻辑层， 通过调⽤COMMON层中的多种数据模型与VO对象进⾏业务组装，形成业务 对象(SDK或者SDK-CLOUD中定义的对象)向上进⾏输出；API则包含 FACADE，⽤FACADE中输出的业务对象数据对外形成数据接⼝。

可以看⻅，***AFCCS***这个结构，既将分⼯在每个层⾯进⾏了定义，⼜形成 了⼀个内外兼顾的双循环闭环，以此模型来指导开发者的⽇常开发，可以很 好的划分代码界限与代码模块中的任务分⼯，在不考虑编码⽔平的层⾯上， 较⼤地提升了代码的可读性，让研发者可以更有章法的去写代码与阅读代码，同时也通过标准化做了⼀定程度的解耦⼯作。

**模型标准化图例：**

![f2ec6a2d3b25e2d4c2a567bfade43ab5.png][]

###  ###

## 标准化的实践——脚手架结构 ##

刚刚我们说完了技术标准化既需要接⼝定义的标准化有需要研发模型的标准 化，可是，这些毕竟都是理论意义上的⽅法论，对于实际⼯作中我们仍然需要⼀个 具象的脚⼿架框架来辅助我们码代码、搭积⽊，将微服务中出⼊数据与代码结构进 ⾏约束的同时，也将技术进⾏统⼀选型。

在这⾥，我将⽤公司内部的***Labrador***框架进⾏举例。

**脚手架框架结构：**

![43306c111120eab296e7b7d5b0f80339.png][]

脚⼿架框架按照功能划分模块，研发⼈员将按照⾃⼰需求⾃主选⽤对应的模 块。那么，***Labrador***是如何做的技术选型呢，这⾥，我们也⽤xmind进⾏了罗 列。

**技术框架：**

![351fd16c647bf63f7fef752cb5c47340.png][]

**数据库集成：**

![d02d42de438468e8738e6c6aada7a97b.png][]

**中间件：**

![8a1137c5bac603a5192d42ec250a7b42.png][]

**devops：**

![7f93a07d63a9326848d8e20d9329add2.png][]

###  ###

## 标准化的实践——基于脚⼿架的业务规范 ##

聊完了技术标准化与脚⼿架是什么后，我们肯定也需要在业务结构上有所标 准，这样可以辅助我们脚⼿架中的技术选型与对应业务节点中，我们该⽤怎样的脚 ⼿架组件。

在此，不多做赘述，我们拿⼀个物联⽹项⽬举例，直接上业务形态结构图。

**业务形态结构：**

![213ee157accf07e42ef9d6f04d9b26cc.png][]

有了业务形态的辅助，我们可以针对业务节点进⾏不同的技术选型，并且从 脚⼿架中获取具体的功能模块进⾏业务实现与实践。

###  ###

## Ending ##

好了，今天就和⼤家聊到这⼉，也感谢看到最后的⼩伙伴，希望能够多提提 建议，⼤家也可以多在评论区交流，后续我们也将进⼀步详细地介绍我们的脚⼿架 是如何在具体项⽬业务中进⾏⼯作和⽇常开发。

***THANKS！***

[f2ec6a2d3b25e2d4c2a567bfade43ab5.png]: https://img-blog.csdnimg.cn/img_convert/f2ec6a2d3b25e2d4c2a567bfade43ab5.png
[43306c111120eab296e7b7d5b0f80339.png]: https://img-blog.csdnimg.cn/img_convert/43306c111120eab296e7b7d5b0f80339.png
[351fd16c647bf63f7fef752cb5c47340.png]: https://img-blog.csdnimg.cn/img_convert/351fd16c647bf63f7fef752cb5c47340.png
[d02d42de438468e8738e6c6aada7a97b.png]: https://img-blog.csdnimg.cn/img_convert/d02d42de438468e8738e6c6aada7a97b.png
[8a1137c5bac603a5192d42ec250a7b42.png]: https://img-blog.csdnimg.cn/img_convert/8a1137c5bac603a5192d42ec250a7b42.png
[7f93a07d63a9326848d8e20d9329add2.png]: https://img-blog.csdnimg.cn/img_convert/7f93a07d63a9326848d8e20d9329add2.png
[213ee157accf07e42ef9d6f04d9b26cc.png]: https://img-blog.csdnimg.cn/img_convert/213ee157accf07e42ef9d6f04d9b26cc.png