关于java:微服务开发系列开篇

1 开篇

微服务现如今曾经是一个被绝大多数开发人员都熟知的概念了。

网上各种微服务开发系列层出不穷，各类的微服务框架也多如牛毛。

然而，在这样一种好像没什么必要介绍微服务的工夫点，我还是要给出一系列我对于微服务开发的了解。

这些了解并不深奥，这些做法你可能每天都在做，某些中央你可能认为十分根底。

然而在我的了解中，这些很重要，并没有花里胡哨的实现形式，技术的目标，不是为了用繁琐的办法实现简略的目标，而是为了用简略的办法，实现所有目标。

因而我想介绍的框架，一切都是为了不便，不便排查，不便部署，不便开发，它只是一个不便的零碎。

这些简略的技巧，浮夸的做法，不仅仅为微服务框架提供无益的设计形式，还对一些开发人员的开发习惯和对开发的了解上，也可能有着一些助力。

2 源码地址

great-microservice-gradle-kotlin

下面的我的项目源码，是笔者本人亲手搭建并不断完善的，后续所有的《微服务框架系列》都是基于此写出。

源码应用 kotlin 开发，然而能够无缝转为 java。

后续我会独自写一篇我为什么要应用 kotlin。

3 系统结构

这是一个基于 gradle 构建微服务架构。

\--- server
    +---framework
    +---gateway
    \---business
        +---business-foundation
        +---business-web

其中领有子节点的我的项目，是一个没有代码的治理我的项目，治理下体面我的项目的构建，依赖等。

4 各个模块的作用

4.1 server

整个微服务架构中的顶层我的项目，自身不蕴含任何代码，是所有我的项目的顶层我的项目。

领有上面的性能：

1. 治理我的项目都须要用到的依赖版本
2. 定义了所有我的项目必须领有的依赖，比方所有我的项目都须要依赖 framework，hutool，spring-security，spring-cloud，spring-admin-client，spring-redisson，spring-alibaba-nacos-config，spring-alibaba-nacos-discovery，caffeine
3. 定义打包中须要蕴含或者排除的文件
4. 定义各个我的项目的构建形式
5. gradle 依赖仓库
6. 依赖的 gradle 插件
7. 设置其它一些共用参数

4.2 server:framework

根底模块，我的项目中所有的模块都须要依赖该模块，在 server 中曾经设置好，领有上面的性能：

1. 所有我的项目独特须要应用类和 spring boot starter 主动装载的 bean。
2. 包含了 http 申请中，我的项目所需应用的共用类
3. jackson 封装
4. redisson 基于 jackson 的序列化配置
5. spring 数据对立序列化

4.3 server:gateway

网关模块，作用相似于 nginx，领有上面的性能：

1. 网关转发
2. 跨域设置
3. spring security 鉴权、验证码
4. 申请响应中 content 的拦挡打印
5. 全局申请日志打印、采集
6. 为所有申请的 response 中加上 cost 耗时监控，
7. 为所有申请的 response 中加上 request-id 申请惟一 id，并且传递到上游，可能在上游追踪日志
8. knif4j swagger 服务中心

有一些性能我的项目到了肯定规模须要做的，目前未实现

1. 申请限流
2. 熔断

该模块应用了 webflux，是 spring cloud gateway 应用的 web 框架，有别于传统的 servlet。

4.4 server:business

业务模块，是一个小型的顶层模块，可能掌控所有的业务模块领有的依赖，构建形式等，因为零碎中大部分雷同的性能都曾经被 server 定义，所以这个模块不须要再做过多的配置，只须要分心解决与下体面业务模块相干的依赖或者配置。

4.5 server:business:business-foundation

是一个相似于 framework 然而仅服务于业务模块的业务根底模块，随着零碎的倒退，可能一直裁减性能，例如某个组件是须要所有业务模块设置的，那么就能够在该模块下，做一个对立的配置。

目前领有的性能：

1. 提供所有业务模块须要独特依赖的业务类，比方业务对象、rpc 近程调用接口类。裁减的准则是

   1. 共享的代码范畴必须限度在 business 下
   2. 代码共享范畴必须至多是两个或者以上的我的项目
   3. 尽量剥离业务逻辑，不能把原本应该放在业务模块中的代码，不加思考的放在这里
2. spring mvc security、跨域、日志、全局异样、http session 配置
3. 一些业务共用参数例如封装的分页参数对象、分页后果对象
4. mybatis plus 配置

4.6 server:business:business-web

一个零碎的外围业务模块，这类模块为零碎提供业务能力，是和外接环境交互最多的模块，这类模块能够分为多个，当业务过于简单的时候，就能够思考剥离开来，缩小一个模块的复杂度。

然而剥离为多个时又须要思考好每个业务模块之间的连贯如何设计，须要思考蕴含但不仅限于上面这些问题：

1. 共用业务类如何剥离
2. 零碎间服务如何互相调用
3. fegin 的应用该如何设计

这些问题不仅要在开发前思考，在开发和需要一直变动的过程中也要一直思考，以求其可能疾速的适应新的开发方式。

相比于思考下层，开发反而是最简略的事件，只有下层构造定义好了，剥离与合并都是非常不便的事件。

这个微服务框架这样设计，就是为了在小中型零碎中尽量获取更多的灵活性。

5 架构中应用到的第三方服务

在架构用采纳一些第三方服务，应该要认真思考引入的服务将会带来什么样的影响，在利用过程中，应该要一直地对服务自身的优缺点进行考量。

怎么样应用第三方服务，才是正当的、正确的，我在应用到上面的这些服务时，或多或少都会有一些问题，一直地磨合，寻找适合的解决办法，是一个不断进步的过程。

零碎中援用过的第三方服务有下列这些，前面的一些章节，会具体阐明一些服务为什么要这样用， 更重要的是为什么不要这样用 。

5.1 mysql

目前应用的 orm 是 mybatis plus，mp 尽管好用，然而须要有一些限度，前面会介绍到。

5.2 redis

应用的客户端是 redisson，对于 redisson 的序列化前面会介绍。

5.3 nacos

作为注册核心和配置核心，其自身性能不错，然而也有一些问题和额定的配置。

5.4 elasticsearch

应用原生的 RestHighLevelClient，不思考 spring data。

不应用 spring data 的起因次要有两个

1. elasticsearch 的版本升级太快，spring data 有点跟不上节奏
2. spring data 的应用，须要三个版本统一，spring data 自身的版本，spring boot 的版本，elasticsearch 的版本，应用条件太刻薄

6 总结

这个微服务架构，由顶至下设计了整个我的项目的构造，尽可能的利用一些可能利用到的个性，把我的项目中与业务无关的代码全副剥离开来，让所有的模块都能享受到在一个整体架构中的劣势，明确各个模块各自的职能，找到本身模块的定位。

这些职能并不是惟一不变的，每个零碎都能够依据本身的理论状况去调整这个构造，架构也不是变化无穷的，齐全能够依据理论状况去做扭转，然而尽量要遵循最大解耦的准则，并在任何状况中考量扭转的影响，以不便开发人员开发的同时，也能保护框架自身的稳定性。

这个框架只是适宜一些中型的零碎，中型的零碎体量上不会过于宏大，如果在这个架构中呈现了十几个甚至几十个模块的时候，就要思考到这个架构是否适合了，可能须要更加适宜的架构去开发了，可能会产生多个中型我的项目相互配合的状况，甚至可能呈现与业务联合严密的网关模块。

同样也不适宜一些小型我的项目，因为没有这个必要，简略开发一些业务性能，并且随后很难在裁减的状况下，只须要一个独自 spring boot 就能够实现所有性能。

因而没有一个框架是惟一的，能解决任何问题的。

这一系列的文章，是为了可能形容出一个现实的框架，是如何在一直思考的过程中，与各种服务不合理的中央做奋斗，与各种开发习惯互相磨合，又如何做出斗争，一直进化的过程，从而可能帮忙更多的开发者加深对框架的了解，在面对任何第三方服务时，都可能熟能生巧的做出正当的抉择。

本文参加了思否技术征文，欢送正在浏览的你也退出。