本文是Dave Kerr发表的一篇微服务批判性文章，他认为复杂性是导致微服务将死的一个重要原因，实际上微服务本来是解决复杂性的，将牵一动百的单体架构变成很多独立发展的服务，相互隔离，复杂性关键是因为隔离不清还是现实世界根本无法隔离分清或者没有能力去隔离？其实单体系统最大问题是单点风险，而微服务化解了单点风险，但是这种化解是依靠多点替代单点，当然这个多点粒度也不能太细，否则如果从单点逻辑角度去看微服
转载
2024-05-15 13:22:22
55阅读
大部分项目部署中，为了方便，可能都直接使用kill -9 服务的pid来停掉服务。但是由于Eureka采用心跳的机制来上下线服务，会导致服务消费者调用此已经kill的服务提供者然后出错。可以采用以下方式来解决：核心是先调用方法主动通知Eureka注册中心服务下线，然后再停掉服务。 本文会介绍几种eureka 注册中心服务下线的方式 最不可取的就是直接使用kill命令
转载
2024-05-28 08:50:02
78阅读
什么是EurekaServer自我保护模式？默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当Eu
转载
2024-04-11 13:47:13
43阅读
在过去的几年里，我对多个正在进行数字化转型的产品团队进行了架构审查。发现大多数团队都会使用微服务架构来构建产品，他们使用微服务架构的意图都是正确的：更快的开发速度、更好的可扩展性、更小的独立团队、独立的部署、使用合适的技术来完成工作等等。但大多数时候，我发现团队在使用微服务时都很不顺利，他们没能利用微服务的优势。在这篇文章中，我将分享导致你的微服务走向失败的 11 个原因。对于刚接触微服务的人来说
前言永远记得：微服务不是代表系统快、微服务不代表性能就好了。相反，实施了微服务后如果你没有掌握好要领，你反而会比没实施微服务“死了更惨”。这句话非常有意思。我们不急，看下去。通过一个实际例子我们来看没有微服务带来的危害先。2021年11月27号因为用户模块中访问直播间的一条API被卡死后发生的事。实例例子在我们的生产上，用户模块内访问微信直播间API，互联网一侧（微信直播间应该是发生了一次网络抖动
转载
2024-04-02 21:57:35
76阅读
一、什么是服务雪崩服务雪崩效应是一种因“服务提供者的不可用”（原因）导致“服务调用者不可用”（结果），并将不可用逐渐放大的现象。解释上面这句话：服务提供者不可用，比如，服务提供者A服务的访问压力过大，或者是网络原因，硬件原因等等多种因素，造成了服务提供者的不可访问。此时，相应的服务调用者B服务，就无法成功调用其提供的接口，并且造成线程阻塞，挤压线程。随着调用次数的增多，挤压的线程越来越多，那么这个
转载
2024-02-26 17:05:35
118阅读
网关的作用微服务架构中，服务实例的地址可能经常会发生变化，所以我们不能直接将服务的地址暴露出来。如果每一个微服务都直接暴露接口，会导致一系列的问题，比如调用过于复杂，涉及到账户、权限不能统一处理等。另外基于高内聚低耦合的设计准则来讲，我们也应该将内部系统和外部系统做切割。因此，这时就需要有一个独立的组件来处理外部的请求，这个组件就是服务网关。服务网关就是为了简化前端的调用逻辑，通常情况下也会实现相
转载
2024-08-18 13:31:53
113阅读
概述互联网应用发展到今天，从单体应用架构到 SOA 以及今天的微服务，随着微服务化的不断升级进化，服务和服务之间的稳定性变得越来越重要，分布式系统之所以复杂，主要原因是分布式系统需要考虑到网络的延时和不可靠，微服务很重要的一个特质就是需要保证服务幂等，保证幂等性很重要的前提需要分布式锁控制并发，同时缓存、降级和限流是保护微服务系统运行稳定性的三大利器。随着业务不断的发展，按业务域的划分子系统越来越
转载
2024-05-17 13:20:01
42阅读
一.微服务雪崩问题一.分布式系统问题由于网络的不稳定性，决定了任何一个服务的可用性都不是 100% 的。当网络不稳定的时候，作为服务的提供者，自身可能会被拖死，导致服务调用者阻塞，最终可能引发雪崩效应。二.可能产生雪崩的原因：1.服务不可用：缓存击穿、大量的请求、程序bug、硬件故障、资源耗尽等导致服务不可用 2.流量过大：由于用户或者代码逻辑重试三.现象：1.开始线程1中微服务D不可用了，线程1
转载
2024-04-23 20:53:41
218阅读
您真的在为您的应用
原创
2022-08-10 08:52:39
121阅读
在过去的几年中，我已经对处于数字化转型过程中的多个产品团队进行了架构审查。大多数团队都在按照微服务架构构建产品。他们有使用基于微服务的体系结构的所有正确意图-更快的开发，更好的可伸缩性，更小的独立团队，独立的部署，使用正确的技术来完成工作，等等。但是，我经常发现团队在微服务方面苦苦挣扎。他们未能充分利用微服务的优势。在这篇文章中，我将分享我认为团队在微服务方面苦苦挣扎的原因。微服务架构风格是一种将
转载
2024-04-29 23:16:53
217阅读
导读：我两年前的预测变成了现实，现在时间又到了2014年的年底，希望再做一次预测：App已死，服务永生。 前几日，有位创业者和我讲他在带领团队做一个将爱踢球的人集中在一起的App，我告诉他你的创业方向错了。原因在于你的目的是要为爱踢球的人提供服务，而你现在却在竭尽全力的做App，你应该做的是设计你为爱踢球者提供哪些服务，App只是你提供服务中的一个不是全部。 2012年12月我曾写过一篇文章《
转载
精选
2014-11-25 12:57:29
2069阅读
点赞
VCL已死，RAD已死 ——SD2C中未能尽言的话题<<<-- 上一节五、后RAD时代：领域的成熟－－－－－从界面可视，到界面可描述的变化，使UI设计渐已成为一个相对独立领域。
转载
2008-12-25 21:52:00
191阅读
2评论
OpenStack 已死？！经常经常被问到这个问题“OpenStack怎么了”， 比如人们认为OpenStack已经在走下坡路了。在回答之前，我会先做个无奈的表情。其实是OpenStack发生了一些变化。OpenStack项目仍然非常健康，并遵循通常的炒作曲线：OpenStack项目终于成熟了，所以人们认为OpenStack已经在走下坡路了是可以理解的。OpenStack logo问这个问题的人一
原创
2021-05-08 14:47:33
1052阅读
最近在整理历史的研究文档的时候发现了还保有了一些有关 DITA 的文档。随着技术的发展，DITA 显得非常臃肿了，并且编译处理并不是非常友好。查询了下官方的版本历史：已经有差不多 2 年没有更新了，由此看来 DITA 作为文档交付应该已经是日薄西山了。应该没有什么人通过写 XML 的方式来写文档了。相反，MD 和 AsciiDoc 格式的文档却大行其道。其主要原因是能够随意部署，并且文档结构少，约束少，更加容易写作和阅读。作为文档来说，内容是最主要的，格式相对来说没有那么重.
原创
2021-08-11 09:20:45
215阅读
# Java已死？——探究Java的现状与前景
## 引言
近年来，有人声称"Java已死"，这种言论引起了广泛讨论。Java作为一种老牌编程语言，曾经在开发界占据重要地位。本文将从几个方面探讨Java的现状与前景，并给出一些代码示例来说明Java依然具有活力。
## Java的现状
Java自诞生以来便备受关注，其强大的跨平台性、丰富的类库和广泛的应用领域使其成为软件开发的首选语言之一。
原创
2023-08-26 10:04:11
83阅读
我不会骗你，在云服务上发生微服务崩溃，然后试图弄清究竟发生了什么事情是难以置信的令人沮丧。重新启动并运行另外一个实例很简单，但不知道前一个实例失败的原因的话，你不能保证新服务的稳定性会比替换掉的更稳定。 在本文中，我们将看看你可以使用哪些策略来更好地了解什么情况下会导致你的微服务崩溃。充分了解它失败的原因将让你有机会去实施更改以提高微服务的稳定性，并有望避免再次发生同样的问题。 当为时已晚
转载
2024-05-08 22:36:55
308阅读
最近在整理历史的研究文档的时候发现了还保有了一些有关 DITA 的文档。 随着技术的发展，DITA 显得非常臃肿了，并且编译处理并不是非常友好。 查询了下官方的版本历史： 已经有差不多 2 年没有更新了，由此看来 DITA 作为文档交付应该已经是日薄西山了。应该没有什么人通过写 XML 的方式来写文
转载
2021-01-18 21:27:00
157阅读
2评论
# 如何实现“hadoop已死”
## 整体流程
首先，我们需要明确整个流程，以便小白能够清晰地了解如何实现“hadoop已死”。下面是实现该任务的步骤表格：
```mermaid
erDiagram
理清思路 --> 下载hadoop
下载hadoop --> 安装hadoop
安装hadoop --> 配置hadoop
配置hadoop --> 启动had
原创
2024-07-09 03:48:14
48阅读
刚刚听说了国产编程语言“木兰”诞生了，于是很开心地搜索了一下，发现居然是负面新
原创
2023-08-03 22:56:18
106阅读
