[深圳|内门弟子]JAVA-况博凯|2021年05月01日的日报-技能树.IT修真院

发表于： 2021-05-01 22:59:35

1 1206

今天完成的事情：

解决Spring Cloud Config的报错

进一步了解微服务，对MongDB,Docker,Jenkins

还了解一下传统的开发流程到敏捷开发，再到DevOps这样的一个过程

使用spring Cloud Bus刷新配置

学习spring Cloud Sleuth 服务链路追踪

明天计划的事情：

spring Cloud-Admin

spring Cloud-Security

遇到的问题：

报错：

1.连不上github,报错git-upload-pack 解决办法：fq

2. No custom http config found for URL 解决办法： uri: https://github.com/zuowj/learning-demos # 配置git仓库的地址（最后不需要带/,不然就会报这样错误

3.私自配置了本地仓库文件，导致Config Server不知道用那一个，报错找不到文件解决办法：删除本地仓库文件

收获：

解决Spring Cloud Config的报错

===========

看到一个好玩的物理机和虚拟机 + Docker容器的区别

=======

微服务的定义：

1.按业务划分为一个独立运行的程序，即服务单元。一般来说，将访问量大的服务分离出去，比如电商服务中的订单服务等等

2.服务之间通过HTTP协议相互通信。一般通过RestTemplate，按照Restful风格进行通信。辅助通信有 RabbitMQ, 和Dobbo明显的不同，就是Dobbo采用RPC进行通信

3.自动化部署。这个和Jenkins+Docker有关，是为了解决微服务中多个服务部署问题，毕竟不像单体架构一样，只用部署一个war包就行了。

4.可使用不同的编程语言。这个暂时没发现

5.可以使用不同的存储技术。这个就是数据库独立了，对于经常需要读写采用MongDB或者Redis,他们的读写速度很快。每个服务所使用的数据存储技术根据业务来选择。

6.服务集中化管理。比如Eureka 通过Eureka来注册服务和发现服务

7.微服务是一个分布式系统。

分布式系统比单体架构更加的复杂，体现在服务的独立性，服务相互调用的可靠性，还有分布式事务，全局锁，全局id,以及数据的一致性，单体架构不用考虑这些复杂性。由于通信依赖HTTP请求，网络不好，会对分布式带来很大的影响。且在分布式系统中，各个服务互相依赖，一旦一个服务出现问题或者网络延迟，在高并发的情况下，很短的时间内，线程资源会被耗尽，导致该服务不可用。由于服务间相互依赖，可能会导致整个系统都崩溃，这就是“雪崩效应”。于是引入了熔断机制。

===============

开发流程：

带来的好处，风险大小降低，大幅提升了软件开发的效率和版本更新的速度

可是OP（部署还是铁板一块），于是新加入了一种模式：

DevOps（Development Operations）

DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

意思就会变成下面这样：

=======

DevOps其实很早之前就提出来了，但是一直不火。因为当时Docker和Jenkins还没出现，微服务也不常见，可以看到技术和开发流程是相辅相成的。

想到微服务这个不仅仅是spring cloud和Dobbo等等，而是由微服务这个概念带来一整套的改变。spring cloud+Docker+Jenkins+DevOps等等

微服务十分契合DevOps，从早期一个人搞所有步骤，到现在变成每个都只负责了一个微服务下面的一小个设计。给我的感觉开发流程是逐渐在向流水线靠近（想到对工业革命意义重大的流水线生产一样）。

举个例子：早期汽车厂工人工程师贯穿整个生产流程（早期程序员做的事情），到一个汽车厂接不了那么多活，于是打算多开几家厂（集群模式），最后到汽车厂把发动机，变速器和车身交给不同工厂同时进行生产研发，然后再统一调度总装生产（现在的微服务）

===========

使用spring Cloud Bus刷新配置

spring Cloud Bus是什么？

用轻量的消息代理将分布式的服务连接起来，消息总线可以为微服务做监控，也可以实现程序之间相互通信。

为什么要用spring Cloud Bus刷新配置？

因为微服务太多了，一个一个更改配置太麻烦了。

步骤：

第一步，导入依赖：

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-bus-amqp</artifactId>

</dependency>

第二步，添加配置：

spring:

cloud:

config:

label: master

profile: dev

discovery:

enabled: true

serviceId: config-server

bus:

enabled: true

trace:

enabled: true

client:

serviceUrl:

defaultZone: http://localhost:8761/eureka/

rabbitmq:

host: localhost

port: 5672

username: guest

password: guest

application.yml：

management:

endpoints:

web:

exposure:

include: "*"

cors:

allowed-origins: "*"

allowed-methods: "*"

新增 rabbitMQ 端口检测：

//判断 rabiitMQ 是否启动

int rabbitMQPort = 5672;

if(NetUtil.isUsableLocalPort(rabbitMQPort)) {

System.err.printf("未在端口%d 发现 rabbitMQ服务，请检查rabbitMQ 是否启动", rabbitMQPort );

System.exit(1);

}

刷新配置类：

public class FreshConfigUtil {

public static void main(String[] args) {

HashMap<String,String> headers =new HashMap<>();

headers.put("Content-Type", "application/json; charset=utf-8");

System.out.println("因为要去git获取，还要刷新config-server, 会比较卡，所以一般会要好几秒才能完成，请耐心等待");

String result = HttpUtil.createPost("http://localhost:8012/actuator/bus-refresh").addHeaders(headers).execute().body();

System.out.println("result:"+result);

System.out.println("refresh 完成");

}

运行：

============

spring Cloud Sleuth 服务链路追踪：

spring Cloud Sleuth是什么？

是一个分布式链路追踪组件，封装了Dapper,Zipkin和Kibana等组件，通过它可以知道服务之间相互依赖的关系，并实时观察链路的调用情况。

单纯的理解链路追踪，就是指一次任务的开始到结束，期间调用的所有系统及耗时（时间跨度）都可以完整记录下来。

Spring Cloud Sleuth 提供了以下功能：

链路追踪：通过 Sleuth 可以很清楚的看出一个请求都经过了那些服务，可以很方便的理清服务间的调用关系等。

性能分析：通过 Sleuth 可以很方便的看出每个采样请求的耗时，分析哪些服务调用比较耗时，当服务调用的耗时随着请求量的增大而增大时，可以对服务的扩容提供一定的提醒。

数据分析，优化链路：对于频繁调用一个服务，或并行调用等，可以针对业务做一些优化措施。

可视化错误：对于程序未捕获的异常，可以配合 Zipkin 查看。

为什么要使用spring Cloud Sleuth？

因为微服务架构是一个分布式架构，微服务系统按照业务划分服务单元，一个微服务系统往往有很多个服务单元。然后一个请求可能会调用多个服务单元，这时候，一旦出错，找出错误是一件很复杂的事情，那么这个时候就需要spring Cloud Sleuth 为我们来找出一个请求的参与过程。

=========

简单实现：

1.对 product-data-service和 product-view-service-feign 两个 pom.xml 里都增加 zipkin依赖

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-zipkin</artifactId>

</dependency>

2.两个的配置文件都加上

zipkin:

base-url: http://localhost:9411

3.在启动类里配置 Sampler 抽样策略： ALWAYS_SAMPLE 表示持续抽样

@Bean

public Sampler defaultSampler() {

return Sampler.ALWAYS_SAMPLE;

}

4.启动 zipkin-server-2.10.1-exec.jar

备注：

因为视图服务进行了改造，支持了 rabbitMQ, 那么在默认情况下，它的信息就不会进入 Zipkin了。在Zipkin 里看不到视图服务的资料了。

为了解决这个问题，在启动 Zipkin 的时候带一个参数就好了：

java -jar zipkin-server-2.10.1-exec.jar --zipkin.collector.rabbitmq.addresses=localhost

即本来是：

java -jar zipkin-server-2.10.1-exec.jar

===========

==========

返回列表

【任务9】 [深圳|内门弟子]JAVA-况博凯 | 2021年05月01日 的日报 上品

评论

分享到

【任务9】 [深圳|内门弟子]JAVA-况博凯 | 2021年05月01日的日报上品