【公益】开放一台Eureka注册中心给各位Spring Cloud爱好者
【公益】开放一台Eureka注册中心给各位Spring Cloud爱好者
程序猿DD 发表于6个月前
【公益】开放一台Eureka注册中心给各位Spring Cloud爱好者
  • 发表于 6个月前
  • 阅读 778
  • 收藏 26
  • 点赞 3
  • 评论 7

标题:腾讯云 新注册用户域名抢购1元起>>>   

这是一篇博客福利!

相信很多关注Spring Cloud的爱好者们,不论是读我的系列文章和书籍还是看其他朋友们写的博客佳文,都不可避免的启动多个项目来体验Spring Cloud带来的整套微服务架构方案。其中,Eureka注册中心几乎是每个试验都必须要启动的应用。在整个学习过程中,我们不厌其烦的启动它,为了让微服务之间能够正常的发现并调用服务接口。

所以...我花了点业余时间,对Spring Cloud Eureka Server的UI增加了一些说明,并将在博客上公开出来给Spring Cloud的初学者和开发者们使用,大家可以方便的使用它来调试我博客和《Spring Cloud微服务实战》书中的诸多示例,或是利用此开发和调试自己的应用。

该Eureka注册中心关闭了自我保护机制,所以当各位开发者的服务下线后,稍等片刻就会被剔除,所以大家不用担心服务的长时间停留在该服务注册中心上。说了那么多,这个开放的注册中心在哪里呢?请看下面,它主要分为两部分:

关于该服务注册中心的源码如下,欢迎给予Star支持!

共有 人打赏支持
粉丝 239
博文 39
码字总数 52404
评论 (7)
smallchill
非常感谢
ddatsh
每次看见LZ名称都很纠结。。。
测试基准域
好人一生平安:pray:
开源中国首席董事长
别的服务,名称和我的冲突了 怎么办?
hantsy
这东西从一开始就不喜欢。去年一个大型项目Research过程中,试用过 Spring Cloud 全套后,排除其大部分项目, 除了 Log, Feign这些项目相对有用,其它的都不用。特别是 eureka, config , 一旦用上,你的代码就被绑架了。服务代码本身不应该包含应该任何编排方面的东西。
1. 所有服务器编排的方面的功能尽可能用容器实现,Docker 1.12 引入DNS功能,自带 Service Discovery, Docker Swarm支持 Cluster多节点。Kubernetes中,config, service discovery 早已不是问题。
2. 使用 Spring Cloud(Eureka, Config等),每个服务本身应该集成在自己业务处理,却被用来服务编排的配置绑架了,代码耦合了本应该属于服务编排的配置,额外需要太多的资源去处理其它 Spring Cloud 组件的交互,使用服务本身的可用性大大降低。
3. 马大叔的文章每个服务都是应该包含一个 Proxy,Spring Cloud Sidecar 可以做这一点:服务与编排配置分离,由sidecar 负责编排方面的处理,但这项目的初忠是为非 Java 语言服务准备。更多的时候还是喜欢 Linkrd 部署时配置。
ixiaohei

引用来自“hantsy”的评论

这东西从一开始就不喜欢。去年一个大型项目Research过程中,试用过 Spring Cloud 全套后,排除其大部分项目, 除了 Log, Feign这些项目相对有用,其它的都不用。特别是 eureka, config , 一旦用上,你的代码就被绑架了。服务代码本身不应该包含应该任何编排方面的东西。
1. 所有服务器编排的方面的功能尽可能用容器实现,Docker 1.12 引入DNS功能,自带 Service Discovery, Docker Swarm支持 Cluster多节点。Kubernetes中,config, service discovery 早已不是问题。
2. 使用 Spring Cloud(Eureka, Config等),每个服务本身应该集成在自己业务处理,却被用来服务编排的配置绑架了,代码耦合了本应该属于服务编排的配置,额外需要太多的资源去处理其它 Spring Cloud 组件的交互,使用服务本身的可用性大大降低。
3. 马大叔的文章每个服务都是应该包含一个 Proxy,Spring Cloud Sidecar 可以做这一点:服务与编排配置分离,由sidecar 负责编排方面的处理,但这项目的初忠是为非 Java 语言服务准备。更多的时候还是喜欢 Linkrd 部署时配置。
看来你还没有用好spring cloud。
大后锋

引用来自“hantsy”的评论

这东西从一开始就不喜欢。去年一个大型项目Research过程中,试用过 Spring Cloud 全套后,排除其大部分项目, 除了 Log, Feign这些项目相对有用,其它的都不用。特别是 eureka, config , 一旦用上,你的代码就被绑架了。服务代码本身不应该包含应该任何编排方面的东西。
1. 所有服务器编排的方面的功能尽可能用容器实现,Docker 1.12 引入DNS功能,自带 Service Discovery, Docker Swarm支持 Cluster多节点。Kubernetes中,config, service discovery 早已不是问题。
2. 使用 Spring Cloud(Eureka, Config等),每个服务本身应该集成在自己业务处理,却被用来服务编排的配置绑架了,代码耦合了本应该属于服务编排的配置,额外需要太多的资源去处理其它 Spring Cloud 组件的交互,使用服务本身的可用性大大降低。
3. 马大叔的文章每个服务都是应该包含一个 Proxy,Spring Cloud Sidecar 可以做这一点:服务与编排配置分离,由sidecar 负责编排方面的处理,但这项目的初忠是为非 Java 语言服务准备。更多的时候还是喜欢 Linkrd 部署时配置。
K8S本来和spring cloud就有重合。但不是每个公司都有能力使用k8sa啊= =
×
程序猿DD
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: