微服务

微服务架构已经很流行了，并且有大量文章描述相对单体架构，微服务架构带来的众多优点。 怎么从单体架构更优雅地转化为微服务架构呢？ 有一种被实践证明有效的方法论：The Twelve-Factor App[1]

从Java Agent报错开始，到JVM原理，到glibc线程安全，再到pthread tls，逐步探究Java Agent诡异报错。

也就是在这一年，B 站开始正式用 Go 重构 B 站，从此B站的API网关技术子开始了从0到1的持续演进。。。

Go + gRPC-Gateway(V2) 构建微服务实战系列，小程序登录鉴权服务：第一篇(内附开发 demo)

前端云原生，以 Kubernetes 为基础设施的高可用 SSR(Vue.js) 渲染微服务初探（开源 Demo）

进入新世纪互联网时代后，以腾讯和阿里为代表的社交电商巨头开始面临流量和复杂度大增的挑战。此时的研发团队相较于之前已经明显扩大，并开始实践 SOA /微服务架构，比如阿里的 HSF。

2021年天猫双十一落下帷幕，支撑数千亿交易的阿里中间件也全面升级到公有云架构。如何有效利用云产品做好我们的业务大促备战，这是一个大家都比较关心的问题。今天趁着618大促来袭前，谈一谈我们所积累的最佳实践。

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

SpringCloud - 微服务之多模块化(一)

阿里巴巴早在2018年，就开启了云原生上云的序幕，将容器、服务网格作为核心技术点进行演进，并尝试阿里巴巴和蚂蚁通过这次技术演进，来统一双方的中间件技术栈，让业务更聚焦业务开发，屏蔽底层分布式复杂度。 作为服务网格一个重要方向，我们开启了下一代网关的探索之路。

通常我们可以在前端通过防抖和节流来解决短时间内请求重复提交的问题，如果因网络问题、Nginx重试机制、微服务Feign重试机制或者用户故意绕过前端防抖和节流设置，直接频繁发起请求，都会导致系统防重请求失败，甚至导致后台产生多条重复记录，此时我们需要考虑在后台增加防重设置。

微服务迁移不是一个小更改。你必须搞清楚它是否真的能解决你的问题，否则你可能会创建一个会杀死你的、乱糟糟的实体。 单体有不同类型，其中一些可能是有效的，足以满足业务需求。单体不是一个应该被杀死的敌人。 微服务关乎独立部署。有一些分解和增量更改模式可以帮助你评估并迁移到微服务架构。 当你开始使用微服务时，你会意识到随之而来的是一系列非常复杂的挑战。所以不应该将微服务作为默认选择。你得仔细考虑它们是否适合你。

这章我们来介绍在系统中引入redisson-spring-boot-starter依赖来实现redis缓存管理 1、在GitEgg-Platform中新建gitegg-platform-redis用于管理工程中用到的Redis公共及通用方法。

Ribbon是Netflix下的负载均衡项目，它主要实现中间层应用程序的负载均衡。为Ribbon配置服务提供者地址列表后，Ribbon就会基于某种负载均衡算法，自动帮助服务调用者去请求。Ribbon默认提供的负载均衡算法有多种，例如轮询、随即、加权轮训等，也可以为Ribbon实现自定义的负载均衡算法。 Ribbon有以下特性：

本人最近学习了一下微服务下数据一致性的特点，总结了下目前的保障微服务下数据一致性的几种实现方式如下，以备后查。此篇文章旨在给大家一个基于微服务的数据一致性实现的大概介绍，并未深入展开，具体的实现方式本人也在继续学习中，如有错误，欢迎大家拍砖。 传统应用的事务管理 本地事务 在介绍微服务下的数据一致性之前，先简单地介绍一下事务的背景。传统单机应用使用一个RDBMS作为数据源。应用开启事务，进行CRUD，提交或回滚事务，统统发生在本地事务中，由资源管理器（RM）直接提供事务支持。数据的一致性在一个本地事务中得到保证。

绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此，本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。

绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此，本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。

PassJava 初始化项目和添加微服务

APISIX是基于云原生的微服务API网关，它是所有业务流量的入口，可以处理传统的南北向流量(server-client)，也可以处理服务间的东西向流量(server-server)，也可以当做 k8s ingress controller 来使用。

尽管很早我们就做了会员、商品、交易的服务化，但流量入口还是php主站，php实际上仍是一个单体应用，单体应用无需网关。当全站java化之后，单体应用将被拆分为微服务，自然需要一个网关来负责统一流量入口、鉴权、安全防护、业务统一处理等。

我们要聊微服务的话，就不得不说系统架构设计的三个阶段了 单体集中式架构 分布式架构 微服务架构

JeecgBoot单体升级微服务之二（3）

.Net微服务实战之负载均衡（下）（二）

.Net微服务实战之Kubernetes的搭建与使用（一）

Proxyless Service Mesh 能力将跟随 Dubbo-go 下一版本发布，稳定的性能需要社区成员们共同的关注与建设。在此基础之上，我们还会进一步探索轻量级 sdk + sidecar的模型；探索基于第三方流量治理组件的金丝雀发布能力；探索基于 dubbo 服务框架的多语言 sevice mesh、与更丰富的 mesh 生态组件兼容。

微服务的设计模式，你用了几个

提高微服务安全性的11个方法

微服务的下一步，离不开服务网格

系统架构演变：SOA、微服务架构的区别和联系

Dubbo，是由阿里巴巴技术团队，在生产中实际应用的解决方案； Spring Cloud，由netflix，则是Spring 成熟的框架，演变出的微服务架构解决方案； Kubernetes（K8S），是由谷歌技术团队，在生产中，应用的解决方案。

Docker:打包微服务项目成docker镜像

Dubbo+zookeeper微服务架构之服务注册与发现的简单使用

如何落地可灰度、可观测、可回滚的安全生产三板斧能力，满足业务高速发展情况下快速迭代和小心验证的诉求，是企业在微服务化深入过程中必须要面对的问题。在云原生流行的当下，这个问题又有了一些新的思路与解法。

分治策略 divide and conquer 微服务 数据库 水平拆分

关于虚拟机这块阿粉以前玩的也很多，但很少总结，容易遗忘，今天索性一条龙总结搞定！

深入Java微服务之网关系列1：什么是网关

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

调用链路是 Sentinel 的工作主流程，由各个 Slot 槽组成，将不同的 Slot 槽按照顺序串在一起，从而将不同的功能（限流、降级、系统保护）组合在一起； 本篇《2. 获取 ProcessorSlot 链》将从源码级讲解如何获取调用链路，接着会以遍历链表的方式处理每一个 Slot 槽，其中就有：FlowSlot、StatisticSlot、DegradeSlot 等。分别对应本篇《3. 流控槽实施流控逻辑》、《4. 统计槽实施指标数据统计》和《5. 熔断槽实施服务熔断》；

1、路由转发：接收一切外界请求，转发到后端的微服务上去； 2、过滤器：在服务网关中可以完成一系列

Apache APISIX 助力有赞云原生 PaaS 平台，实现全面微服务治理（2）

接下来的章节，White带着大家以微服务架构和设计模式落地实战的方式，进行讲解和实现SpingCloud的代码开发。那么在开始项目之前，你可以仔细阅读如下介绍信息，方便你能更加快速的进入学习。