辰小白

入门篇SpringCloud——微服务架构介绍SpringCloud——springboot、springcloud如何使用合适的版本SpringCloud——搭建分布式架构-父工程搭建SpringCloud——idea删除模块后，重新创建同名模块！踩坑！！SpringCloud——支付子模块构建SpringCloud——热部署DevtoolsSpringCloud——消费者订单模块及服务间调用SpringCloud——工程重构，抽取重复代码构建通用公共服务初级篇.

通过前面我们创建的订单模块、支付模块、可以发现都用到了相同的实体类及json返回类。这样重复了，所以现在我们将订单模块、支付模块中重复用到的类抽取出来，创建一个复用的公共模块打成jar包，使其一处部署，处处通用。系统中重复部分下面我们创建一个公共模块:cloud-api-commons用于存放一些重复代码、服务接口、工具类等。。。创建和之前支付模块一样，然后配置pom.xml文件<?xml version="1.0" encoding="UTF-8"?>...

模块名：cloud-consumer-order80这里模拟用户端下订单，所以服务端口直接80步骤和支付模块一样建module 改pom 写yml 主启动 业务类代码：一、建module这里忽略、参考前面支付模块的建立二、改pompom.xml<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns

1.添加 devtools jar包到我们的模块工程中，pom.xml文件配置代码如下： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope&g

以前的Java项目中，充斥着太多不友好的代码：POJO的getter/setter/toString；异常处理；I/O流的关闭操作等等，这些样板代码既没有技术含量，又影响着代码的美观，Lombok应运而生。任何技术的出现都是为了解决某一类问题，如果在此基础上再建立奇技淫巧，不如回归Java本身，应该保持合理使用而不滥用。Lombok的使用非常简单：1）引入相应的maven包<dependency> <groupId>org.projec...

这里我们模拟下订单然后支付业务，这里定义两个微服务模块，订单order模块、支付payment模块大致建立流程：建module 改pom 写yml 主启动 业务类一、建立微服务支付模块在父工程下新建支付子模块选定jdk子模块名称命名下一步完成后这里碰到一个坑，请大家一定的留意留意SpringCloud——idea删除模块后，重新创建同名模块！踩坑！！二、支付模块pom文件<?xml versio...

今天在做微服务架构创建子模块的时候，遇到了一个坑删除模块后，重新创建同名模块时，出现src下的java、resource无法识别（见下图），其实就是创建失败。经过一番排查后，终于发现了问题，打开根模块的.idea下的misc.xml打开misc.xml后，可以看到以下标签内容。cloud-provider-payment8001这个模块名被添加进ignoreFiles的集合中，意味着重新创建名为cloud-provider-payment8001时，就会被忽略，导致创建模块失败，所以要解决这个问题只

一、使用技术版本及拟定场景技术版本本次工程模拟订单支付功能将下列技术挨个添加进来详情见下图（×的表示之前的组件，现在停更了的；√的表示新的替换后的组件）描述请见：SpringCloud——微服务架构介绍二、搭建Project父工程new一个project，按图片步骤执行命名工程名字选择maven版本 下一步后点击maven自动加载jar包完成构建设置工程编码格式注解激活生效由于后续需要用到很多注解，以及第三方注解，所...

由于springboot和cloud版本选择上的不匹配，会出现很多搭建或使用上的问题，所以小白在这里建议大家严格按照官方提供的建议进行适合的版本选择。一、如何看boot与cloud的版本是否匹配这里我们以springcloud官网的标准为准则。springcloud官网：https://spring.io/projects/spring-cloud/打开后我们可以看到这个界面我们往下翻至springcloud兼容表Spring Cloud 采用了英国伦敦地铁站的名...

一、微服务架构概述什么是微服务？微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库为什么使用微服务架构？优点：每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求开发简单、开发效率提高，一个服务可能就是专一的只干一件事。 微服务能够被小团队单独开发，这个小团队是2到5人的开发人