ITPub博客

作为互联网公司的研发工程师，微服务的架构思想对于各位读者朋友来说，已经不是陌生东西。我们当中的大多数人，或多或少经历过从单体应用到微服务化的系统拆分和演进过程。我们按照庞大系统的业务功能和特征，将其从一个单体的大应用，逐渐地拆分成很多的子系统的协同配合完成业务功能，甚至拆分后的某些子系统服务，还可能再拆分出来更多的更细颗粒度的子系统服务。拆分后的服务之间，采用PRC调用方式的通信，也就越来越多。随之而来的，跨系统服务之间的数据一致性的问题就会越来越突出了。比如电商系统中营销活动系统的积分和优惠券的发放和扣减，比如电商系统的核心下单核心链路上，首页瀑布流，商详页，下单页等等商品价格全链路一致性等等，支撑这些业务功能的实现，往往可能需要依赖来自N个不同的业务系统服务提供的数据读写服务能力来完成。

上篇文章结尾和小伙伴们留了一个小问题，就是关于 optimize table 命令，今天我想花点时间再来和小伙伴们聊一聊这个话题。

现在，在大型的软件工程系统中，微服务化的系统设计，成为了大部分时候的必然之选。 而如何将微服务做有效的设计，则是需要每一个团队和工程师都需要考虑的一个问题。在保持系统的一致性、可理解性、可维护性和可扩展性上，需要有一些基本的指导原则。 下面分享微服务设计和实践中的8个基础原则，具体如下：

PostgreSQL 16，开源关系型数据库的下一个主要更新，已经发布了一个测试版，主要特点是在查询执行、逻辑复制、开发者体验和安全性方面的改进。

经过半年的沉淀 Spring Boot 3.1于2023年5月18日正式发布了，带来了许多令人兴奋的新特性和改进。 本篇博客将详细介绍Spring Boot 3.1的新特性、升级说明以及核心功能的改进。

物客服工单系统主要承载着得物与用户关联需要客服处理的事件，其主要功能可以认为有如下两项：

他们经过分析后认为如果上国产数据库，必须用分布式的。我问他为什么，他说主要是考虑今后业务量的问题，三五年后有可能交易量翻翻。我就和他算了一下每秒1000笔核心交易大致的负载，相当于一分钟三万六千笔。虽然说银行核心交易和TPMC没有直接换算公式，不过在目前的一台两路PC服务器上，BENCHMARK轻轻松松就可以跑60万的今天，这确实也不算个事儿了。因此对于此类用户，甚至说对大多数用户来说，怕单机处理能力不足是没必要的。

规范约束的是数仓建设的全流程，以及后续的迭代和运维。事实上，数仓规范文档，应该随着架构设计文档，在数仓开发启动之前，分发给所有相关人员，且是所有人都必须严格遵守的约定。

数据准确性是指可以作为可靠信息来源的无错误记录。

Dubbo是一款高性能、轻量级的分布式服务框架，它提供了丰富的服务治理能力，其中服务注册与发现是其中的重要组成部分。服务注册与发现允许服务提供者将自己的服务注册到注册中心，同时让服务消费者从注册中心发现并调用服务。 本文将深入探讨Dubbo服务注册与发现的基本概念、架构设计、实现方式、应用场景和优化措施，希望能为读者提供更全面的理解和应用实践。

在软件行业内，有一句关于技术实用性的名言：“过早优化是万恶之源。” 在局部代码层面上的追求先进，是无可厚非的事情。

那如何设计一份可以提高API的可读性、可理解性和可维护性的呢？ 以RESTful接口的设计为例，下面是10条有效的建议：

service mesh可谓现在最前沿的技术之一，其中istio更是广为流传，但是实际上istio可不是唯一，还有很多优秀的service mesh框架均有独特的功能特性，有自己特别的优势。 本文精选了8个热门的优秀Service Mesh框架进行介绍，干货有点多，慢慢看来~

service mesh可谓现在最前沿的技术之一，其中istio更是广为流传，但是实际上istio可不是唯一，还有很多优秀的service mesh框架均有独特的功能特性，有自己特别的优势。 本文精选了8个热门的优秀Service Mesh框架进行介绍，干货有点多，慢慢看来~

OpenFeign 组件的前身是 Netflix Feign 项目，它最早是作为 Netflix OSS 项目的一部分，由 Netflix 公司开发。后来 Feign 项目被贡献给了开源组织，于是才有了我们今天使用的 Spring Cloud OpenFeign 组件。

从本周开始正式启动【开源挖呀挖】系列，每周五更新一期，挖掘云原生领域开源的优秀项目，分享最前沿的云原生技术，欢迎大家持续关注。 本周我们第一期【2023-05-19】挖到的是API Gateway领域，这是云原生领域中非常重要的一个方向。

首先，从名字上看，这两个注解意义特别接近，@AutoConfigurationPackage 就是自动配置包，自动配置包的目的是能让系统扫描到包内的 Bean；@ComponentScan 则是组件扫描，这个松哥在之前的教程中也多次提到过了，就不再赘述了，所以这里就有一个问题，这两个注解有啥区别？

我见过许多 Linux 性能工程师将 CPU 使用率中的 "IOWait" 部分看作是表明系统何时受到 I/O 限制 的东西。在这篇博客中，我将解释为什么这种方法不可靠以及可以使用哪些更好的指标。 让我们从运行一个小实验开始——在系统上产生大量的 I/O 使用：

Java是一门非常流行的编程语言，由于其跨平台性、可移植性以及强大的面向对象特性而备受青睐。Java最初由Sun Microsystems公司于1995年推出，随着时间的推移，Java发展迅速，版本不断更新。本篇博客将重点介绍Java 17与Java 8的对比，以及Java 17的新特性。

MariaDB 是由 Michael Widenius 在 2009 年发起的（担任同名公司 CTO 一职），该项目是 MySQL 的一个分支。他同样也是 MySQL 的创始人之一，成立 MariaDB 是因为在 Sun Microsystems 收购 MySQL 后，对其独立性产生了担忧。