长河的博客

微服务，这三个字正在席卷着目前的互联网软件行业，尤其在近几年云原生迸发后，似乎人人都对微服务有了更广泛的使用和理解，张口就是各种各样的问号，有着强大的好奇心。无独有偶，我有一个朋友鲤鱼在内部微服务的早期（每个业务组起步）就经常遇到下述的对话：张三：为什么要拆现在的代码？ 鲤鱼：因为 ！@）&@！）！&）@！&！ 的原因。 张三：那即将要做的 “微服务” 是按照什么维度去拆分的服务？ 鲤鱼：常见的一般根据 ！@#*@！#&！（@&！@）#@ 的方式来拆分。

最近一项工作就是在做customer-service的项目重构, 最开始的时候customer-service是crm-service中的一个模块,现在把他拆分出来, crm-service中还包含的木块有resource-serivce, trade-service, sales-service, workflow-service, 都拆分出来, 尽量做到数据库的独立, 因为现在yd_cloud这个库里面有几百张表了,首先理清customer-serive项目中涉及到的表, 全部记录下来, 分库的时候

我告诉你们为啥我要先从eureka首先获取 goods的服务ip, 在用ip的方式使用http调用goods的服务.因为公司的规定, 不让我们用Feigin. 我TMD的都震惊了, 我都不知道为啥. 我也不想写同事的ip地址, 做配置, 因为都去eureka里面注册了, 所以就这样调用了, 真是蛋疼. 这种微服务, 这种奇葩的方式..package com.util;imp...

感谢你能看到这里, 说明上面的博客, 你可能看过了吧(我也就只能这样安慰下自己了), 但愿你有所收获了.现在推荐一些关于<微服务>的书, 希望你能够掌握自己的道 , 微服务的原理至关重要, 别人总结的都是自己的, 需要你自己看书总结,实践 .才能有所收获.那才是属于你自己的.所有书目都上传到百度网盘了, 这里推荐大家去买正版书 , 多多的支持一下作者 , 因为写这种...

Spring Cloud已经放弃Netflix Zuul了。现在Spring Cloud中引用的还是Zuul 1.x版本，而这个版本是基于过滤器的，是阻塞IO，不支持长连接。Zuul 2.x版本跟1.x的架构大一样，性能也有所提升。既然Spring Cloud已经不再集成Zuul 2.x了，那么是时候了解一下Spring Cloud Gateway了。Netflix Zuul 1.x VS...

在前面的章节中, 我们使用order 去调用product的服务, 然后就出现了,问题, 非常不容易去调试, 也没有办法去跟踪各个服务.不用担心, 跟踪微服务的必备组件, 这里介绍的是zipkinSpring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。Zipkin是一款开源的分布式实时...

在order-service服务中, 因为涉及到了对product-service的服务调用, 现在假设万一product宕机了, order 得不到返回数据了, 岂不是一起跟着宕机, 然后就会发生连链式效应, 造成整个服务的不可用, 当product不可以用了, 我们应该把他隔离开来.做好各个服务的错误处理方式, 能够提高服务的稳健性以及可用性.在分布式环境中，许多服务依赖项中的一些...

下面来讲一下zuul的综合使用, 在限流, 请求的校验, 请求处理后的添加处理方面的应用.这个就是网关的优势了.zuul 中不同组件的作用/** * 前置 pre * 限流 鉴定权限 参数校验 请求转发 * * 后置 post * 统计 日志 * 因为zuul 和eureka 一样都是作为微服务中最基本的服务存在, 当zuul 挂了之后, 就...

Zuul是Spring Cloud全家桶中的微服务API网关。所有从设备或网站来的请求都会经过Zuul到达后端的Netflix应用程序。作为一个边界性质的应用程序，Zuul提供了动态路由、监控、弹性负载和安全功能。Zuul底层利用各种filter实现如下功能：认证和安全 识别每个需要认证的资源，拒绝不符合要求的请求。 性能监测 在服务边界追踪并统计数据，提供精确的生产视图。 动态路由 ...

其实在统一配置中心的时候就应该开始说rabbitmq 了, 但是没有说, 所以这里专门说下rabbitmq.rabbitmq 在配置中心作为消息的传递来使用了.rabbitmq的原理, 具体使用, 请查阅这个https://blog.youkuaiyun.com/u010398771/article/details/84136959现在的mq开源的不要太多了, 我最先用的activ...

微服务做完了之后肯定不是使用jar包启动的方式 进行运行了, 我们使用能够间隔进程的docker.使用docker进行服务的部署, 当然了, 还在docker外面再包装一层, 使用rancher 来进行容器服务的部署安装,这里我们就简单的说下,各个服务使用docker 运行起来的过程.以eureka-server为例:打开eureka-server 所在的文件夹. 打开cmd,运...

新建完product 和 order 项目就会发现, 里面有很多的配置是重复的了.(order 和 product 还没有分库, 这个暂时没有做, 记住就行了, 暂时不这么做)现在我们需要做的就是做一个服务专门提供各个服务的配置文件, 进行所有项目配置文件的统一管理, 更新.新建一个叫做config-server 的项目,作为配置中心的服务端 (注意先把你本地的rabbitMQ启动了)...

先闲扯几句 , 其实不想写这么原理, 理论什么的, 因为本系列的博客侧重点在于spring cloud 的使用. 其中的原理也不是我这么点10多篇博文就能写明白的.后来又浏览了这一系列的博客, 还是加进去了很多的文字性的表述,希望你们能学到一些. 因为我没有时间去打字打那么多的废话.如果想知道理论, 请直接到最后一篇博文去, 有书目推荐.看完了上面两个, 就可以做一个eureka...

恭喜你的第一步应该跑起来了吧, 没有就留言, 或者去群里问我吧, 肯定是可以跑起来的.现在我们已经完成了eureka的单个注册中心的新建, 万一这个注册中心挂了怎么办, 其他的服务不就不能通过应用的名字找到彼此了, 他们从此就失散了, 我可不想这样的悲剧发生 ,所以我们要做注册中心的高可用, 简单点说其实就是注册中心之间相互注册.我们要做的就是:eureka-server2 ...

本一系列springcloud的文章主主要讲应用, 也会涉及到一些原理的讲解.写了几句自己这段时间看书,总结的微服务的东西送给你们 :道为源,源分多支为术,如龙生九子,九子各不同,然皆为龙也.凡物发必依其理,当知其源,勿学其术而不究其道,执其道而轻其术,可矣.道为源头,从源发可以发展出很多的形态就是术,就想龙生九子,九子各不同,但是他们的源头都是龙.需要掌握事物发展的根源...

Spring cloud 天气项目系统,是一个简单的小型项目,从第三方的接口获取天气,并进行储存,能对外提供天气的查询服务的一个项目.首先我们对其进行一个单体项目的实现,包括以下的功能:根据现有的xml文档,从中获取所有的城市名字 从第三方根据城市的名字或者城市id获取具体的天气信息 根据名字获取所有的城市天气,并保存在redis中 设置定时任务,每30分钟去更新一遍所有的城市...