微服务防火墙友好策略
在对比RPC与restful时，大致有几点： 1. 协议：http相对更规范，更标准，更通用，无论哪种语言都支持http协议；RPC协议性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能达到http的二倍 2. 安全性:基于Http更安全一些，默认80端口，防火墙友好
传统微服务框架如何无缝过渡到服务网格ASM
服务网格ASM是一个统一管理微服务应用流量、兼容Istio的托管式平台。通过流量控制、网格观测以及服务间通信安全等功能，服务网格ASM可以全方位地简化您的服务治理，并为运行在异构计算基础设施上的服务提供统一的管理能力，适用于Kubernetes集群、Serverless Kubernetes集群、ECS虚拟机以及自建集群。
传统微服务框架如何无缝过渡到服务网格ASM
软件技术的发展历史，从单体的应用，逐渐演进到分布式应用， 特别是微服务理念的兴起，让大规模、高并发、低延迟的分布式应用成为可能。 云原生时代下，微服务框架本身也在不断地进化和迭代演进。 本文主要介绍如何传统微服务框架 SpringCloud 、Dubbo 如何无缝过渡到服务网格ASM
使用 Nocalhost 开发 Rainbond 上的微服务应用
本文将介绍如何使用 Nocalhost 快速开发 Rainbond 上的微服务应用的开发流程以及实践操作步骤。 Nocalhost 可以直接在 Kubernetes 中开发应用，Rainbond 可以快速部署微服务项目，无需编写Yaml，Nocalhost 结合 Rainbond 加速我们的微服务开发效率。
Springboot 整合 SpringCloud组件-Eureka 微服务 EurekaClient（二）
Springboot 整合 SpringCloud组件-Eureka 微服务 EurekaClient（二）
SpringCloud微服务实战——搭建企业级开发框架（四十）：使用Spring Security OAuth2实现单点登录(SSO)系统
目前每家企业或者平台都存在不止一套系统，由于历史原因每套系统采购于不同厂商，所以系统间都是相互独立的，都有自己的用户鉴权认证体系，当用户进行登录系统时，不得不记住每套系统的用户名密码，同时，管理员也需要为同一个用户设置多套系统登录账号，这对系统的使用者来说显然是不方便的。我们期望的是如果存在多个系统，只需要登录一次就可以访问多个系统，只需要在其中一个系统执行注销登录操作，则所有的系统都注销登录，无需重复操作，这就是单点登录(Single Sign On 简称SSO)系统实现的功能。
漫谈！如何简单明了通过分解和增量更改将单体迁移到微服务
微服务迁移不是一个小更改。你必须搞清楚它是否真的能解决你的问题，否则你可能会创建一个会杀死你的、乱糟糟的实体。 单体有不同类型，其中一些可能是有效的，足以满足业务需求。单体不是一个应该被杀死的敌人。 微服务关乎独立部署。有一些分解和增量更改模式可以帮助你评估并迁移到微服务架构。 当你开始使用微服务时，你会意识到随之而来的是一系列非常复杂的挑战。所以不应该将微服务作为默认选择。你得仔细考虑它们是否适合你。
SpringCloud微服务实战——搭建企业级开发框架（十七）：Sentinel+Nacos配置持久化
Sentinel Dashboard中添加的规则是存储在内存中的，我们的微服务或者Sentinel一重启规则就丢失了，现在我们将Sentinel规则持久化配置到Nacos中，在Nacos中添加规则，然后同步到Sentinel Dashboard服务中。Sentinel 支持以下几种规则：流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则 和 热点参数规则。具体可查看官网 Sentinel 规则
SpringCloud微服务实战——搭建企业级开发框架（十一）：集成OpenFeign用于微服务间调用
作为Spring Cloud的子项目之一，Spring Cloud OpenFeign以将OpenFeign集成到Spring Boot应用中的方式，为微服务架构下服务之间的调用提供了解决方案。首先，利用了OpenFeign的声明式方式定义Web服务客户端；其次还更进一步，通过集成Ribbon或Eureka实现负载均衡的HTTP客户端。
面试官：微服务下数据一致性的有几种实现方式，分别说一下
本人最近学习了一下微服务下数据一致性的特点，总结了下目前的保障微服务下数据一致性的几种实现方式如下，以备后查。此篇文章旨在给大家一个基于微服务的数据一致性实现的大概介绍，并未深入展开，具体的实现方式本人也在继续学习中，如有错误，欢迎大家拍砖。 传统应用的事务管理 本地事务 在介绍微服务下的数据一致性之前，先简单地介绍一下事务的背景。传统单机应用使用一个RDBMS作为数据源。应用开启事务，进行CRUD，提交或回滚事务，统统发生在本地事务中，由资源管理器（RM）直接提供事务支持。数据的一致性在一个本地事务中得到保证。
解决微服务架构下流量有损问题的实践和探索
绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此，本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。
如何基于盘古开发框架开发Dubbo微服务网关
在盘古开发框架下实现将微服务发布为 HTTP 接口有两种方式。一种是基于 pangu-web 模块的接口调用模式；一种是基于 ShenYu 网关的泛化调用模式。
Devops 开发运维高级篇之微服务持续集成代码上传和代码检查
微服务持续集成(1)-项目代码上传到Gitlab 微服务持续集成(2)-从Gitlab拉取项目源码 微服务持续集成(3)-提交到SonarQube代码审查
阿里微服务注册中心 Nacos 启动报错 Unable to start embedded Tomcat
阿里微服务注册中心 Nacos 启动报错 Unable to start embedded Tomcat
[半翻] 设计面向DDD的微服务
在DDD中，应用层依赖于领域和基础设施层，而基础设施依赖于领域层，但是领域层不依赖于任何层。 只在领域层编写业务规则和通用的领域知识，而应用层负责针对软件的目标来组合、协调领域层的业务规则。 领域层的领域实体、值类型、聚合根反映了真实业务的核心，需要用一种通用的语言来定义，这样不管应用层多么复杂，核心领域层自岿然不动。 领域层不能直接依赖与基础设施层，现代ORM框架一般都提出仓储模型来帮助领域层和技术设施层解耦。
Dubbo-go-Mesh 开启新一代 Go 微服务形态
Proxyless Service Mesh 能力将跟随 Dubbo-go 下一版本发布，稳定的性能需要社区成员们共同的关注与建设。在此基础之上，我们还会进一步探索轻量级 sdk + sidecar的模型；探索基于第三方流量治理组件的金丝雀发布能力；探索基于 dubbo 服务框架的多语言 sevice mesh、与更丰富的 mesh 生态组件兼容。
架构师的独白：微服务架构是这样的...
项目和人类一样，总是会死亡的，有时候会突然死亡，有时候回自然死亡；在自然死亡这一边，有的人去世的很早，有的人则寿命很长，长寿的人，通常都是生活更规律的；项目也一样，框架更好的项目活的更久，框架不好的项目，上线同时就死亡了。
企业深入使用微服务后会面临哪些问题？云原生全链路灰度给了新思路
如何落地可灰度、可观测、可回滚的安全生产三板斧能力，满足业务高速发展情况下快速迭代和小心验证的诉求，是企业在微服务化深入过程中必须要面对的问题。在云原生流行的当下，这个问题又有了一些新的思路与解法。
PHP 基于 SW-X 框架，搭建RPC微服务支持
SW-X的微服务也可用于优化FPM业务，底层使用了TCP通讯协议，支持基于AES的数据加解密支持，官方提供了Swoole/FPM下的RPC客户端，并提供了纯基于Redis存储管理的RPC服务中心。
从微功能到微服务的系统设计演进
莫希特·古普塔（Mohit Gupta） 8分钟阅读 自从我从事软件开发事业以来，我经历了各种设计原则和模式。但是，一个原则非常突出，以至于发明了许多新的应用程序开发方法，模式和结构来与之保持一致。这就是PoSR的“单一职责原则”。而且为什么不这样，它对代码的结构，可读性，可维护性，发布，团队负责以及端到端所有权产生了巨大影响。 我已经看到了各种形式和形状的实现。正如上面提到的文章中提到的那样，此原则是关于由一个代码单位承担一项责任。“代码单元”取决于用户是谁，因此，取决于“谁是客户”，应用程序，模块，程序包，类，功能都可以称为代码单元。无论单元是什么，方向都是使实现更具
