-
编辑 删除
Go微服务全链路跟踪详解
在微服务架构中，调用链是漫长而复杂的，要了解其中的每个环节及其性能，你需要全链路跟踪。它的原理很简单，你可以在每个请求开始时生成一个唯一的ID，并将其传递到整个调用链。该ID称为CorrelationID¹，你可以用它来跟踪整个请求并获得各个调用环节的性能指标。简单来说有两个问题需要解决。第一，如何
-
编辑 删除
Go微服务容错与韧性(Service Resilience)
ServiceResilience是指当服务的的运行环境出现了问题，例如网络故障或服务过载或某些微服务宕机的情况下，程序仍能够提供部分或大部分服务，这时我们就说服务的韧性很强。它是微服务中很重要的一部分内容，并被广泛讨论。它是衡量服务质量的一个重要指标。ServiceResilience从内容上讲翻
-
编辑 删除
微服务的数据库设计
单独的数据库：微服务设计的一个关键是数据库设计，基本原则是每个服务都有自己单独的数据库，而且只有微服务本身可以访问这个数据库。它是基于下面三个原因。优化服务接口：微服务之间的接口越小越好，最好只有服务调用接口（RPC或消息），没有其他接口。如果微服务不能独享自己的数据库，那么数据库也变成了接口的一部
-
编辑 删除
一个可以自我进化的微服务框架
你是否遇到过这样的框架，它非常简单又是轻量级的，很容易上手，然而当你的项目变得复杂的时候它能自我进化成功能强大的重量级框架，而不需要把整个项目重写?我是从来没见过。先让我们来看一下项目的生命周期。通常，当一个新项目开始时，我们不知道它能持续多久，所以我们希望它尽可能简单。大多数项目都会在短时间内夭折
-
编辑 删除
架构设计之「 微服务入门 」
微服务这几年不可谓不火，很多技术团队都开始在自己的项目上引入了微服务。一方面这些团队确实很好的推动了微服务的应用和发展，另一方面也可以看到一些盲目追技术热点的行为所带来的危害，比如很多中小团队对微服务的基础知识只是做了很浅显的了解就开始盲目的推动微服务的实施，最后导致了项目的失败。微服务要想做好是一
-
编辑 删除
微服务架构之「 服务注册 」
微服务架构是一个庞大复杂的工程，为什么说它庞大复杂呢？因为想要做好微服务，就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章《架构设计之「微服务入门」》中已经初步介绍过了这些组件，包括：服务注册、服务网关、配置中心、服务框架、服务监控、服务追踪、服务治理等。只有将这些基础设施搭建完善了
-
编辑 删除
微服务架构之「 API网关 」
在微服务架构的系列文章中，前面已经通过文章《架构设计之「服务注册」》介绍过了服务注册的原理和应用，今天这篇文章我们来聊一聊「API网关」。「API网关」是任何微服务架构的重要组成部分。有了它我们可以在一个独立的模块上方便的处理一些非业务逻辑，可以让微服务本身专注在自身特定的功能上，使得每个微服务的开
-
编辑 删除
微服务架构之「 配置中心 」
在微服务架构的系列文章中，前面已经通过文章《微服务架构之「服务网关」》介绍过了在微服务中服务网关的原理和应用，今天这篇文章我们继续来聊一聊微服务中另外一个重要模块：「配置中心」。后面还会继续介绍服务框架、服务监控、服务治理等。还是那句话，只有将这些基础设施弄清楚了，微服务实践的道路才能走的稳、走的远
-
编辑 删除
微服务架构之「 监控系统 」
在微服务架构的系列文章中，前面已经通过文章分别介绍过了微服务的「服务注册」、「服务网关」、「配置中心」，今天这篇文章我们继续来聊一聊另外一个重要模块：「监控系统」。因为在微服务的架构下，我们对服务进行了拆分，所以用户的每次请求不再是由某一个服务独立完成了，而是变成了多个服务一起配合完成。这种情况下，
-
编辑 删除
微服务架构之「 调用链监控 」
「调用链监控」是在微服务兴起后才有的一种新流行的监控模式。因为在我们传统单体应用的项目中，不存在服务链/调用链的概念，所以也就根本没有调用链监控的需求了。当我们开始微服务架构之后，我们的很多服务变成分布式的了，并且我们对服务进行了拆分，拆分之后，用户的一个请求进来，会依次经过不同的服务节点进行处理，
-
编辑 删除
微服务架构之「 容错隔离 」
我们知道，在单体应用的架构下一旦程序发生了故障，那么整个应用可能就没法使用了，所以我们要把单体应用拆分成具有多个服务的微服务架构，来减少故障的影响范围。但是在微服务架构下，有一个新的问题就是，由于服务数变多了，假设单个服务的故障率是不变的，那么整体微服务系统的故障率其实是提高了的。比如：假设单个服务
-
编辑 删除
微服务架构之「 访问安全 」
应用程序的访问安全又是我们每一个研发团队都必须关注的重点问题。尤其是在我们采用了微服务架构之后，项目的复杂度提升了N个级别，相应的，微服务的安全工作也就更难更复杂了。并且我们以往擅长的单体应用的安全方案对于微服务来说已经不再适用了。我们必须有一套新的方案来保障微服务架构的安全。在探索微服务访问安全之
-
编辑 删除
微服务架构之「 下一代微服务 Service Mesh 」
ServiceMesh被大家称为下一代的微服务，是微服务领域的一颗新星，被大家讨论的非常多。我在大家的讨论中，还看到有人说“目前的微服务架构我都没学会呢，现在又来一个下一代微服务，真学不动了”。哈哈，没办法，互联网技术就是发展得这么快，这些技术其实也都是由于大家所在的公司业务规模和复杂度变大以后所推
-
编辑 删除
颠覆微服务认知：深入思考微服务的七个主流观点
一群同频者，一起成长，一起精进，打破认知的局限性。一、逃离单体系统，拥抱微服务？单体系统和微服务的区别在于，一个单体系统是一个大而全的功能集合，每个服务器运行的是这个应用的完整服务。而微服务是独
-
编辑 删除
「微服务架构」微服务架构中的数据一致性
在微服务中，一个逻辑上原子操作可以经常跨越多个微服务。即使是单片系统也可能使用多个数据库或消息传递解决方案。使用多个独立的数据存储解决方案，如果其中一个分布式流程参与者出现故障，我们就会面临数据不一致的风险-例如在未下订单的情况下向客户收费或未通知客户订单成功。在本文中，我想分享一些我为使微服务之间
-
编辑 删除
斗鱼开源首秀——基于 Go 的微服务框架 Jupiter
6月1日，斗鱼将基于Go语言的微服务框架Jupiter开源。作为国内知名的互联网直播公司，这也是斗鱼首次以公司的名义正式推出开源项目。近年来，得益于日渐增长的高并发业务需求，微服务架构开始在国内逐渐普及。同时，专为高并发而生的Go语言及其相关生态在国内的发展也突飞猛进。目前，市面上主流的微服务架构包
-
编辑 删除
从Spring Cloud到Kubernetes的微服务迁移实践
写在前面要出发周边游（以下简称要出发）是国内知名的主打「周边游」的在线旅行网站，为了降低公司内部各个业务模块的耦合度，提高开发、交付及运维效率，我们在2017年就基于SpringCloud完成了公司内部业务微服务化的改造，并在2019年实现了SpringCloud至UK8S平台的迁移。本文从要出发的
-
编辑 删除
阿里P7推荐：SpringCloud与微服务构建PDF建议人手一份
本书共分为16章：第1章介绍了什么是微服务、为什么需要微服务、微服务的优缺点和挑战，并且将单体架构的系统和微服务架构的系统进行了比较。第2章主要介绍微服务应该具备的功能，以及SpringCloud的基本组件,最后介绍了SpringCloud与Dubbo、Kubernetes之间的比较及优缺点。第3、
-
编辑 删除
微服务中的模式和反模式
微服务中的常见设计模式软件开发者对“四人帮”的《设计模式》一书应该都很熟悉，微服务中也会有一些常见的模式：部署模式如何部署服务是微服务中的一个重要问题，微服务的部署方式非常灵活，有以下的不同选项可供选择（参考http://www.open-open.com/lib/view/open14624344
-
编辑 删除
微服务通信的设计模式
注：本文为翻译内容，首发于社区：微服务通信的设计模式，原文地址：DesignPatternsforMicroservice-To-MicroserviceCommunication-DZoneMicroservices在我的上一篇博客中，我谈到了微服务的设计模式。现在我想更深入地探讨微服务架构中最重
