微服务开发系列：开篇

微服务开发系列：开篇微服务开发系列：为什么选择Kotlin微服务开发系列：为什么使用Gradle搭建微服务开发系列：目录结构，保持文件环境干净微服务开发系列：服务发现，一个小nacos补充微服务开发系列：如何在框架中选择开源工具微服务开发系列：数据库orm使用微服务开发系列：如何打印好日志微服务开发系列：鉴权微服务开发系列：认识序列化的重要性微服务开发系列：设计统一的http接口内容形式微服务开发系列：使用异常特性将异常纳入框架管理微服务开发系列：使用knife4j生成最适合微服务的文档1开启微服务现在已经是大多数开发者都熟悉的概念了。网上各种微服务开发系列层出不穷，微服务框架也是层出不穷。不过，在这种似乎没有必要介绍微服务的时候，我还是要给出一系列我对微服务开发的理解。这些理解并不深刻，你可能每天都在做这些练习，有些地方你可能觉得很基础。但是在我的理解中，这些都很重要，并没有什么花哨的实现方法。技术的目的不是用繁琐的方法来实现简单的目标，而是用简单的方法来实现所有的目标。所以，我要介绍的这个框架，都是为了方便，方便排查，方便部署，方便开发。这只是一个方便的系统。这些简单的技巧和简单的实践，不仅为微服务框架提供了有益的设计方法，也帮助一些开发者养成开发习惯和对开发的理解。2源码地址great-microservice-gradle-kotlin上的项目源码由作者自己搭建并不断完善，后面的《微服务框架系列》都是基于此编写的。源代码使用kotlin开发，但可以无缝转换为java。后面我会单独写一篇文章讲为什么要用kotlin。3系统结构这是一个基于gradle的微服务架构。\---server+---framework+---gateway\---business+---business-foundation+---business-web有子节点的项目是没有代码的管理项目，管理的构建以下子项目、依赖项等4各模块功能4.1server整个微服务架构中的顶层工程，本身不包含任何代码，是所有工程中的顶层工程。具有以下功能：管理项目所需的依赖版本定义了所有项目必须具备的依赖，如所有项目需要依赖framework、hutool、spring-security、spring-cloud、spring-admin-client、spring-redisson,spring-alibaba-nacos-config,spring-alibaba-nacos-discovery,caffeine定义包中需要包含或排除的文件定义各个项目的构建方法gradle依赖仓库依赖的gradle插件on并设置一些其他常用参数4.2server:frameworkbasics模块，项目中的所有模块都需要依赖这个模块，在server中已经设置好，具有以下功能：所有项目需要使用的类和bean自动加载通过springboot启动器。包括项目在http请求中使用的公共类jackson，基于jackson序列化配置封装redissonspring数据统一序列化4.3server:gateway网关模块，类似nginx，有以下功能：网关转发跨域设置spring安全认证,验证码请求响应中内容的拦截打印,全局请求日志打印,所有请求的响应中加入collection,所有请求的响应中加入cost耗时监控,request-id请求唯一id,以及传递给Downstream，可以在下游knif4jswagger服务中心跟踪日志，有一些功能项目需要在达到一定规模后才做，没有实现requests的当前限制。这个模块使用了webflux，它是springcloudgateway使用的web框架，区别于传统的servlets。4.4server：business业务模块是一个小的顶层模块，可以控制所有业务模块的依赖关系和构建方法，因为系统中大部分相同的功能已经由server定义了，所以这个模块不需要又做了很多配置，只需要集中精力处理后面子业务模块相关的依赖或者配置。4.5server:business:business-foundation是业务基础模块，类似于framework，只是服务于业务模块。随着系统的发展，功能可以不断扩展。比如某个组件需要所有业务模块都设置，那么可以在这个模块下，统一配置。目前功能：提供所有业务模块需要依赖的业务类，如业务对象、rpc远程调用接口类等。扩展的原则是共享代码的范围必须限于业务。代码共享的范围至少要有两个以上的项目，尽可能剥离业务逻辑。本来应该放在业务模块中的代码，想都没想就放在这里。mvc安全，跨域，日志，全局异常，httpsession配置封装的分页参数对象，分页结果对象等一些业务常用参数mybatisplus配置4.6server:business:business-web是一个系统的核心业务模块，比如模块是系统提供业务能力，是与外部环境交互最多的模块。这种类型的模块可以分成多个模块。当业务过于复杂时，可以考虑将其分离出来，降低一个模块的复杂度。但是，拆分成多个时，需要考虑如何设计各个业务模块之间的连接，包括但不限于以下问题：公共业务类如何与系统间服务分离，如何相互调用fegin，如何设计这些问题不仅要在开发前思考，更要在开发过程中不断思考，不断变化需求，使其能够快速适应新的开发方式。与上层思考相比，开发是最简单的事情。只要定义好上层结构，拆分合并都是很方便的事情。这个微服务框架就是这样设计的，目的是在中小型系统中获得尽可能多的灵活性。5架构中使用的第三方服务在架构中使用一些第三方服务时，应该慎重考虑引入的服务会带来什么影响。在申请过程中，您应该不断评估服务本身的优缺点。考虑。如何使用第三方服务是合理和正确的。我在使用以下服务时，或多或少都会遇到一些问题。不断调整，寻找合适的解决方案，是一个不断改进的过程。.系统中引用的第三方服务如下。后面的章节会详细解释为什么有些服务应该这样使用，更重要的是为什么不应该这样使用。5.1mysql目前使用的orm是mybatisplus。mp虽然好用，但是需要有一些限制，后面会介绍。5.2redis使用的客户端是redisson，后面会介绍redisson的序列化。5.3作为注册中心和配置中心，nacos本身功能良好，但也存在一些问题和额外配置。5.4elasticsearch使用原生的RestHighLevelClient，不考虑spring数据。没有使用springdata的原因是elasticsearch两个版本升级太快，springdata和springdata的使用有点不同步。三个版本需要保持一致，springdata本身的版本，springboot的版本，elasticsearch的版本。使用条件太苛刻6总结一下这个微服务架构，从上到下设计整个项目的结构，尽可能利用一些可用的特性，剥离所有与业务无关的代码project，让所有模块都能在一个整体架构中发挥优势，明确各个模块各自的功能，找到自己模块的定位。这些功能并不是唯一保持不变的功能。每个系统都可以根据自己的实际情况调整结构。架构不是一成不变的，可以根据实际情况变化，但尽量遵循最大解耦的原则，考虑任何情况下变化的影响，以方便开发者开发，同时保持框架本身的稳定性。这个框架只适用于一些中型系统，中型系统体积不会太大。如果这个架构有十几个甚至几十个模块，你必须考虑这个架构是否合适。你可能需要开发出更合适的架构，多个中型项目可能会相互合作，甚至可能会出现一个与业务紧密结合的网关模块。也不适合一些小项目，因为没有这个需求，而且有些业务功能只是简单开发，后期很难扩展，只需要一个springboot就可以完成所有功能。所以没有一个框架是独一无二的，可以解决所有问题。本系列文章是为了能够描述一个理想的框架，如何在不断思考的过程中对抗各种服务不合理的地方，如何与各种开发习惯磨合，如何做出妥协，不断思考的过程evolution可以帮助更多的开发者加深对框架的理解，在面对任何第三方服务时做出合理的选择。