Browsed by
标签:中间件

最常用的Java框架或者开源项目有哪些?

最常用的Java框架或者开源项目有哪些?

閱讀本文約花費: 19 (分鐘)系统设计 微服务/分布式 基础框架 Spring Boot [1] :Spring Boot 可以轻松创建独立的生产级基于 Spring 的应用程序,内置 web 服务器让你可以像运行普通 Java 程序一样运行项目。另外,大部分 Spring Boot 项目只需要少量的配置即可,这有别于 Spring 的重配置。 spring-cloud-alibaba[2] : Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。 Spring Cloud Alibaba Sentinel[3] :A lightweight powerful flow control component enabling reliability and monitoring for microservices. (轻量级的流量控制、熔断降级 Java 库)。 Dubbo[4] :Apache Dubbo 是一个基于 Java 的高性能开源 RPC 框架。 Nacos[5] :Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮…

Read More Read More

程序员如何把控自己的职业

程序员如何把控自己的职业

閱讀本文約花費: 26 (分鐘)这篇文章的主要内容主要是我今年3月份在腾讯做的直播,主要是想让一些技术人员对世界有一个大体的认识,并且在这个认识下能够有一个好的方法成就自己。而不是在一脸蒙圈的状态下随波逐流,而日益迷茫和焦虑。直播完后,腾讯方面把我的直播形成文字的形式发了出来,我觉得我可以再做一个精编版。所以,有了这篇文章,希望对大家有帮助。 对我来说,在我二十多年的工作经历来看,期间经历了很多技术的更新换代,整个技术模式、业务模式也是一直变来变去,我们这群老程序员成长中所经历的技术比今天的程序员玩的还更杂更多。我罗列一下我学过的,而且还被淘汰掉的技术,大家先感受一下。 – MIS应用开发:FoxPro,PowerBuilder,Delphi – OA:Lotus Notes,VBScripts – 微软:ODBC/ADO,COM/DCOM,MFC/ATL,J++ – 服务器:AIX,HP-UX,SCO Unix – Web:CGI,ISAPI,SOAP – RPC:CICS,Tuxedo – J2EE:Websphere,Weblogic – DB:Sybase,Informix 我想说的是,无论过去还是今天,我们这些前浪和你们后浪所面对的技术的挑战和对技术的焦虑感是相似的,我们那个时候不但玩996,还玩封闭开发(就是一周只能回家一天)。当然,唯一好的东西,就是比起今天的程序员来…

Read More Read More

软件架构万字漫谈:业务架构、应用架构与云基础架构

软件架构万字漫谈:业务架构、应用架构与云基础架构

閱讀本文約花費: 34 (分鐘) 本文首先介绍了架构的分类以及架构模式与架构风格其次介绍了DDD 领域驱动设计和微服务与云原生架构,最后介绍 Kuberentes 应用,了解详情请阅读下文。本文来自于知乎,由火龙果软件Alice编辑、推荐。 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战,就是即能够快速高效地针对需求、环境的变化做出改变,也能够持续提供稳定、高可用的服务。而软件架构,就是软件系统的骨骼与框架。 所谓架构,见仁见智,很难有一个明确或标准的定义;但架构并非镜花水月或阳春白雪,有系统的地方就需要架构,大到航空飞机,小到一个电商系统里面的一个功能组件,都需要设计和架构。抽象而言,架构就是对系统中的实体以及实体之间的关系所进行的抽象描述,是对物/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分,切分的原则,是要便于不同的角色进行并行工作,结构良好的创造活动要优于毫无结构的创造活动。 软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图,它描述的对象是直接构成系统的抽象组件;各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际…

Read More Read More

这多年来我一直在钻研的技术

这多年来我一直在钻研的技术

閱讀本文約花費: 15 (分鐘)因为我是看到tinyfool 《那些年我赶过的时髦技术趋势》(微博原文链接已失效,现更改为Google搜索的内容),在赞叹的时候,也让我对我有好些回忆,所以想写一篇回忆贴,本来觉得回忆是件挺让人沮喪的事,因为是老了的表现,但我写着写着,就歪了楼。看来,我还不老,还在拼博。下面是很多我的唠叨,你喜欢就读读,不喜欢就TLDR – Too Long, Don’t Read! 自从98年毕业,到今天,参加工作有18个年头了,加上在大三的时候就为两个在外面接活的老师程序,到今天,写的程序被用到生产线也有18个年头了。 背景经历 要说明我技术上的“性取向”,还得我说说的我的一些背景和经历。 我这18年,大约分三个阶段: 1996年-2000年:入门乱来期,大三大四加在银行工作的两年。 用Powerbuilder/Delphi在WindowsNT/SQL Server上做了好多个MIS管理软件,有酒店的,有送水的,有OA的。  用Java的Applet做了一个Web的教学课件,用于在Win95/IE3.0中演示操作系统中的各种调度和算法的动画,得了个全国大学生挑战者杯的鼓励奖。  用Delphi的ISAPI技术以及PHP/ASP给一些公司和大学做过几个网站。 2000年-2010年:技术学习期,这十年,我主要的编程语言是C/C++。 前两年在银…

Read More Read More

苏宁高时效、高并发秒杀业务中台的设计与实现

苏宁高时效、高并发秒杀业务中台的设计与实现

閱讀本文約花費: 20 (分鐘) 文章主要介绍了苏宁架构设计背景,苏宁的架构设计以及系统多活部署与单机房宕机场景下的降级方案 设计背景 对于苏宁易购主站而言,正常的用户购物流程囊括选品、下单、库存扣减、付款、订单状态更新、物流履约等。但是在电商业务中往往会涉及到对某些热点商品的秒杀场景。相比于正常购物流程,秒杀场景具有时效性高、并发量大、瞬时业务量极高的业务特性,往往会出现显著的分布式一致性问题。正常的业务系统不能很好地应对瞬时高并发的业务需求,因此就需要针对于秒杀场景进行相应的架构优化,抑或是设计专门用于秒杀的中台业务系统。 就秒杀业务而言,系统在瞬时会达到极高的并发量,如果与其它业务耦合,那么势必会对其它业务造成风险,因此基于安全性考虑和业务隔离原则,秒杀系统在设计上应该与其它系统充分解耦,单独部署。本文将讨论在苏宁现有的技术架构和中台组件的基础上,如何去实现一个通用型秒杀业务中台。 架构设计 1. 系统前端与负载层设计 图一:前端与负载层设计 鉴于秒杀业务本身的高并发特性,对用户请求进行前端分流是必不可少的一步。在系统上游就对部分用户请求进行处理,可以避免海量请求对后端服务器产生过大压力。因为用户往往在秒杀前几分钟就开始点击下单按钮,因此在秒杀开始前可以使用静态资源页面,用户请求由 CDN 直接响应,不必到达后端服务器。 此外,由于秒杀业务的高时效性特征,下单窗口基本集中在秒…

Read More Read More

云原生:「落地」最重要

云原生:「落地」最重要

閱讀本文約花費: 17 (分鐘)1 云原生这个话题虽然我们谈了很多年了,但到底怎么去理解它,还是需要一段过程。提到云原生,很多人会联想到另一个词:「互联网原住民」,这个词代表了一群出生在互联网时代的人,他们看待世界和思考问题的方式从一开始就和互联网时代以前的人不同。 云原生也是如此。未来我们构建任何系统,不再是原来的那套思考方式,不是把云当成一个工具来使用,而是系统本身就生长于云,并在云上爆发,因此需要我们从根本上转换思考方式,重新定义业务系统。云原生和云计算也不一样,云计算的主角是计算、机器、资源,而云原生的主角是云上延伸出来的应用。 阿里云智能事业群总裁行癫曾经写过一个故事: 在 2004 年那个缺电的夏天,淘宝网全都挤在华星二楼:正是在那里,开始了我的淘宝生涯。我的位置在一个角落里,边上是一堆开着的服务器,吹出的风比七月烈阳下的风更热:因为限电,空调基本上只能看。刚到一个新环境,不知道该做什么,眼睁睁地看着一大群人忙忙碌碌。那时淘宝的节奏是非常快的,我记得小宝有一次说,当时网站如果要改点什么,只要跑到多隆那儿说一下,等他接杯水回到座位打开页面时,需求就已经上线了。 那是 2004 年,基于当时的技术架构,任何需求只要改一下代码,就能够立刻交付。而在现在这样复杂的技术架构下,很难通过简单修改代码实现需求迭代。 但是随着云原生时代的到来,我们又看到了新的机会。为了再现“当年的传说…

Read More Read More

语雀的技术架构演进之路

语雀的技术架构演进之路

閱讀本文約花費: 21 (分鐘)每个技术人心中或多或少都有一个「产品梦」,好的技术需要搭配好的产品,才能让用户爱不释手,尤其是做一款知识服务型产品。 作者何翊宇(花名:不四)是蚂蚁金服体验技术部高级前端技术专家,语雀产品技术负责人。本文从技术架构的视角,回顾了语雀的原型、内部服务和对外商业化的全过程,并对函数计算在语雀架构演进过程中所扮演的角色做了详细的介绍。 语雀是一个专业的云端知识库,用于团队的文档协作。现在已是阿里员工进行文档编写和知识沉淀的标配,并于 2018 年开始对外提供服务。 1 原型阶段 回到故事的开始。 2016 年,语雀孵化自蚂蚁科技,当时,蚂蚁金融云需要一个工具来承载它的文档,负责的技术同学利用业余时间,搭建了这个文档工具。项目的初期,没有任何人员和资源支持,同时也是为了快速验证原型,技术选型上选择了最低成本的方案。 底层服务完全基于体验技术部内部提供的 BaaS 服务和容器托管平台: Object 服务:一个类 MongoDB 的数据存储服务; File 服务:阿里云 OSS 的基础上封装的一个文件存储服务; DockerLab:一个容器托管平台; 这些服务和平台都是基于 Node.js 实现的,专门给内部创新型应用使用,也正是由于有这些降低创新成本的内部服务,才给工程师们提供了更好的创新环境。 语雀的应用层服务端,自然而然的选用了蚂蚁体验技术部开源的 No…

Read More Read More

Nacos 企业级落地实践

Nacos 企业级落地实践

閱讀本文約花費: 16 (分鐘)前言 在高速发展的时候,公司规模越来越大,老师人数越来越多,这时候公司不能铺太多人去做运营与服务,必须提高每个人效,这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司,如果被迫成为一家靠资金驱动的公司就活不下去了。 ——张翼(掌门教育创始人兼 CEO) 掌门教育自 2014 年正式转型在线教育以来,秉承“让教育共享智能,让学习高效快乐”的宗旨和愿景,经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ,一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展,特别是今年的疫情,使在线教育成为了新的风口,也给掌门教育新的机遇。 随着业务规模进一步扩大,流量进一步暴增,微服务数目进一步增长,使老的微服务体系所采用的注册中心 Eureka 不堪重负,同时 Spring Cloud 体系已经演进到第二代,第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模,同时它目前被 Spring Cloud 官方置于维护模式,将不再向前发展。如何选择一个更为优秀和适用的注册中心,这个课题就摆在了掌门人的面前。经过对 Alibaba Nacos 、HashiCorp Consul 等开源注册中心做了深入的调研和比较,最终选定 Alibaba Nacos 做微服务体系 Solar 中的新注册中心。 背景故事 掌门教育微服务面临…

Read More Read More

常用的分布式事务解决方案

常用的分布式事务解决方案

閱讀本文約花費: 46 (分鐘)众所周知,数据库能实现本地事务,也就是在同一个数据库中,你可以允许一组操作要么全都正确执行,要么全都不执行。这里特别强调了本地事务,也就是目前的数据库只能支持同一个数据库中的事务。但现在的系统往往采用微服务架构,业务系统拥有独立的数据库,因此就出现了跨多个数据库的事务需求,这种事务即为“分布式事务”。那么在目前数据库不支持跨库事务的情况下,我们应该如何实现分布式事务呢?本文首先会为大家梳理分布式事务的基本概念和理论基础,然后介绍几种目前常用的分布式事务解决方案。废话不多说,那就开始吧~ 什么是事务? 事务由一组操作构成,我们希望这组操作能够全部正确执行,如果这一组操作中的任意一个步骤发生错误,那么就需要回滚之前已经完成的操作。也就是同一个事务中的所有操作,要么全都正确执行,要么全都不要执行。 事务的四大特性 ACID 说到事务,就不得不提一下事务著名的四大特性。 原子性 原子性要求,事务是一个不可分割的执行单元,事务中的所有操作要么全都执行,要么全都不执行。 一致性 一致性要求,事务在开始前和结束后,数据库的完整性约束没有被破坏。 隔离性 事务的执行是相互独立的,它们不会相互干扰,一个事务不会看到另一个正在运行过程中的事务的数据。 持久性 持久性要求,一个事务完成之后,事务的执行结果必须是持久化保存的。即使数据库发生崩溃,在数据库恢复后事务提交的结果…

Read More Read More

阿里巴巴为什么不用 ZooKeeper 做服务发现?

阿里巴巴为什么不用 ZooKeeper 做服务发现?

閱讀本文約花費: 24 (分鐘)历史的迷思 站在未来的路口,回望历史的迷途,常常会很有意思,因为我们会不经意地兴起疯狂的念头,例如如果当年某事提前发生了,而另外一件事又没有发生会怎样?一如当年的奥匈帝国皇位继承人斐迪南大公夫妇如果没有被塞尔维亚族热血青年普林西普枪杀会怎样,又如若当年的丘老道没有经过牛家村会怎样? 2007年底,淘宝开启一个叫做“五彩石”的内部重构项目,这个项目后来成为了淘宝服务化、面向分布式走自研之路,走出了互联网中间件体系之始,而淘宝服务注册中心ConfigServer于同年诞生。 2008年前后,Yahoo 这个曾经的互联网巨头开始逐渐在公开场合宣讲自己的大数据分布式协调产品 ZooKeeper,这个产品参考了Google 发表的关于Chubby以及 Paxos 的论文。 2010年11月,ZooKeeper从 Apache Hadoop的子项目发展为 Apache的顶级项目,正式宣告 ZooKeeper成为一个工业级的成熟稳定的产品。 2011年,阿里巴巴开源Dubbo,为了更好开源,需要剥离与阿里内部系统的关系,Dubbo 支持了开源的 ZooKeeper 作为其注册中心,后来在国内,在业界诸君的努力实践下,Dubbo + ZooKeeper 的典型的服务化方案成就了 ZooKeeper 作为注册中心的声名。 2015年双11,ConfigServer 服…

Read More Read More

让开发部署提速8倍,我参与这款的插件的全过程

让开发部署提速8倍,我参与这款的插件的全过程

閱讀本文約花費: 20 (分鐘)如何像参与开源那样,去参与一款 IDE 插件的设计? 作为一款 IDE 插件的使用者,我是否能决定下一个版本的功能? 自从产品经理银时小伙和他的开发小哥们在去年12月发布 Cloud Toolkit(一款 IDE 插件)以来,已帮助数以万计的开发者们提高了业务的部署效率。期间,开发者们不仅是 Cloud Toolkit 的使用者,同时也作为设计者参与了插件的更新迭代。 本文来自开发者徐靖峰,分享了他和 Cloud Toolkit 的故事 遇见 Cloud Toolkit 在与中间件小姐姐的一次聊天中,偶然间了解到这款插件,小姐姐跟我提到自己正在运营一款 IDE 开发者工具,能够使开发部署效率提高 8 倍,出于好奇心,我就上手体验了一下,看看究竟是一个什么样的产品。使用了一段时间之后,便迫不及待地向小姐姐分享了我作为开发者对插件的一些看法。 我对这款产品最直观的感受:这是一款发布工具,帮助用户在 IDE 中直接打包应用并部署到各种终端。一开始看到这款产品位于阿里云的页面中,原本以为是一款和阿里云服务强绑定的产品,但试用过后才发现,即使对于普通的云主机,也非常适用,还可以解决很多开发运维的痛点,非阿里云用户可以放心使用。 在 Cloud Toolkit 出现之前 作为一个 Java 程序员,我们大多数会在 Intellij IDEA 中基于 S…

Read More Read More

个推微服务网关架构实践

个推微服务网关架构实践

閱讀本文約花費: 9 (分鐘) 文章主要介绍了个推微服务体系的架构,以及个推微服务网关提供的主要功能等,希望能对您有所帮助。 在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过调用N个微服务的接口完成一个用户请求。因此,在客户端和服务端之间增加一个API网关成为多数微服务架构的必然选择。 在个推的微服务实践中,API网关也起着至关重要的作用。一方面, API网关是个推微服务体系对外的唯一入口 ;另一方面, API网关中实现了很多后端服务的共性需求,避免了重复建设 。 个推微服务网关的设计与实现 个推微服务主要是基于Docker和Kubernetes进行实践的。 在整个微服务架构中,最底层的是个推私有部署的Kubernetes集群,在集群之上,部署了应用服务。 个推的应用服务体系共分为三层,最上一层是网关层,接着是业务层,最下面是基础层服务。 在部署应用服务时,我们使用了Kubernetes的命名空间对不同产品线的产品进行隔离。除了应用服务外, Kubernetes集群上还部署了Consul来实现配置的管理、Kube-DNS实现服务注册与发现,以及一些辅助系统来进行应用和集群的管理。 下图是个推微服务体系的架构图。 个推对API网关的功能需求主要有以下几方面: 1. 要支持配置多个产品,为不同的产品提供不同的端口; 2. 动态路由…

Read More Read More

面试官邪魅一笑:MySQL千万级别大表,你要如何优化?

面试官邪魅一笑:MySQL千万级别大表,你要如何优化?

閱讀本文約花費: 23 (分鐘)当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量: 字段 尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT,如果非负则加上UNSIGNED VARCHAR的长度只分配真正需要的空间 使用枚举或整数代替字符串类型 尽量使用TIMESTAMP而非DATETIME, 单表不要有太多字段,建议在20以内 避免使用NULL字段,很难查询优化且占用额外索引空间 用整型来存IP 索引 索引并不是越多越好,要根据查询有针对性的创建,考虑在WHERE和ORDER BY命令上涉及的列建立索引,可根据EXPLAIN来查看是否用了索引还是全表扫描 应尽量避免在WHERE子句中对字段进行NULL值判断,否则将导致引擎放弃使用索引而进行全表扫描 值分布很稀少的字段不适合建索引,例如”性别”这种只有两三个值的字段 字符字段只建前缀索引 字符字段最好不要做主键 不用外键,由程序保证约束 尽量不用UNIQUE,由程序保证约…

Read More Read More

如何设计可以动态扩容缩容的分库分表方案?

如何设计可以动态扩容缩容的分库分表方案?

閱讀本文約花費: 7 (分鐘)面试题 如何设计可以动态扩容缩容的分库分表方案? 面试官心理分析 对于分库分表来说,主要是面对以下问题: 选择一个数据库中间件,调研、学习、测试; 设计你的分库分表的一个方案,你要分成多少个库,每个库分成多少个表,比如 3 个库,每个库 4 个表; 基于选择好的数据库中间件,以及在测试环境建立好的分库分表的环境,然后测试一下能否正常进行分库分表的读写; 完成单库单表到分库分表的迁移,双写方案; 线上系统开始基于分库分表对外提供服务; 扩容了,扩容成 6 个库,每个库需要 12 个表,你怎么来增加更多库和表呢? 这个是你必须面对的一个事儿,就是你已经弄好分库分表方案了,然后一堆库和表都建好了,基于分库分表中间件的代码开发啥的都好了,测试都 ok 了,数据能均匀分布到各个库和各个表里去,而且接着你还通过双写的方案咔嚓一下上了系统,已经直接基于分库分表方案在搞了。 那么现在问题来了,你现在这些库和表又支撑不住了,要继续扩容咋办?这个可能就是说你的每个库的容量又快满了,或者是你的表数据量又太大了,也可能是你每个库的写并发太高了,你得继续扩容。 这都是玩儿分库分表线上必须经历的事儿。 面试题剖析 停机扩容(不推荐) 这个方案就跟停机迁移一样,步骤几乎一致,唯一的一点就是那个导数的工具,是把现有库表的数据抽出来慢慢倒入到新的库和表里去。但是最好别这么玩儿,有点不太…

Read More Read More

微服务与网关技术(SIA-GateWay)

微服务与网关技术(SIA-GateWay)

閱讀本文約花費: 18 (分鐘) 编辑推荐:文章主要介绍了微服务架构特性,微服务网关的分类以及作用,SIA-GateWay等,希望能对您有所帮助。 一. 背景 软件架构,总是在不断的演进中… 把时间退回到二十年之前,当时企业级领域研发主要推崇的还是 C/S 模式,PB、Delphi 这样的开发软件是企业应用开发的主流。随着时间不断的推移,基于浏览器的的 B/S 架构开始渐渐流行了起来。初期,Web 开发 ASP 还占据了不少优势,但 JSP 的预编译模式让性能有了很大的提升,随后基于 JAVA 语言的 J2EE 架构变的越来越流行。 早期软件架构基本都是单体架构,系统之间往往不需要进行交互,这也导致数据孤岛和 ETL 工具的发展。随着企业应用越来多,相互的关系也越来密切。应用之间也迫切需要进行实时交互访问,随后基于 XML 的异构系统集成和数据交互技术开始被很多公司采用,SOA 的概念被提了出来,web service 逐渐流行起来。 互联网时代,很多公司为了适应更加灵活的业务需求,基于 HTTP 协议和 Restful 的架构风格及简洁和结构清晰的 JSON 语言成为企业开发的最佳实践,在 SOA 架构中,企业服务总线技术 ESB 所暴露的集中式架构的劣势让开发者明白基于注册和发现的分布式架构才是解决问题的关键办法。由此,微服务架构逐渐流行起来。 在《微服务设计》中如…

Read More Read More

解Bug之路-记一次存储故障的排查过程

解Bug之路-记一次存储故障的排查过程

閱讀本文約花費: 8 (分鐘)解Bug之路-记一次存储故障的排查过程 高可用真是一丝细节都不得马虎。平时跑的好好的系统,在相应硬件出现故障时就会引发出潜在的Bug。偏偏这些故障在应用层的表现稀奇古怪,很难让人联想到是硬件出了问题,特别是偶发性出现的问题更难排查。今天,笔者就给大家带来一个存储偶发性故障的排查过程。 Bug现场 我们的积分应用由于量非常大,所以需要进行分库分表,所以接入了我们的中间件。一直稳定运行,但应用最近确经常偶发连接建立不上的报错。报错如下: 而笔者中间件这边收到的确是: 这样的告警。整个Bug现场如下图所示: 偶发性错误 之前出过类似register err这样的零星报警,最后原因是安全扫描,并没有对业务造成任何影响。而这一次,类似的报错造成了业务的大量连接超时。由于封网,线上中间件和应用已经稳定在线上跑了一个多月,代码层面没有任何改动!突然出现的这个错误感觉是环境出现了某些问题。而且由于线上的应用和中间件都是集群,出问题时候都不是孤立的机器报错,没道理所有机器都正好有问题。如下图所示: 开始排查是否网络问题 遇到这种连接超时,笔者最自然的想法当然是网络出了问题。于是找网工进行排查,在监控里面发现网络一直很稳定。而且如果是网络出现问题,同一网段的应用应该也都会报错才对。事实上只有对应的应用和中间件才报错,其它的应用依旧稳稳当当。 又发生了两次 就在笔者觉得这个…

Read More Read More

Scroll Up