前言
在之前的文章中我们介绍了服务的拆分和通讯,每一个服务都是一个可独立部署并且数据自治的进程,系统通过服务间的网络通讯完成一个个业务步骤,最终完成一个个完整的工作流。这里的每一个服务都可以部署在相同或者不同的物理空间,数据亦是如此。所以对于微服务或者说原生云架构(Cloud Native)来说分布式是其与生俱来的特性,而就分布式来说数据的一致性是项目开发中必须面临的问题。今天我们就来谈谈微服务如何保证数据的一致性。
在之前的文章中我们介绍了服务的拆分和通讯,每一个服务都是一个可独立部署并且数据自治的进程,系统通过服务间的网络通讯完成一个个业务步骤,最终完成一个个完整的工作流。这里的每一个服务都可以部署在相同或者不同的物理空间,数据亦是如此。所以对于微服务或者说原生云架构(Cloud Native)来说分布式是其与生俱来的特性,而就分布式来说数据的一致性是项目开发中必须面临的问题。今天我们就来谈谈微服务如何保证数据的一致性。
在前面的文章,我们介绍了从工程角度将系统拆分成多个自治服务的好处,但从用户角度,用户并不希望去了解系统背后每一具体的服务,他们更关心的是整个系统的呈现方式以及整个系统的集成度。虽然集成是一个系统级别的概念,但它依赖于服务间可被理解的通讯,只有这样服务才可以相互调用。这篇文章我们一起聊一聊微服务间的通讯。
上一篇文章我们介绍了什么是微服务以及选择微服务必须考虑的一些因素,如果我们最终的答案是肯定的,那么下一步我们就需要考虑如何保证服务设计的一致性、可复用性以及可维护性等一系列非功能性设计约束。这篇文章我们一起聊聊如何利用领域驱动设计(DDD)设计一个好的微服务(希望读者有一定的DDD知识或经验)。
微服务已然不是什么新名词,但是它依旧是一个时尚的名称。虽然它不像区块链技术那样开拓出一块新的领域,但至少在架构领域它在不断的扩大着自己的影响力,并被越来越多的人所接受。在18年的最后一个月我想谈谈自己对微服务的理解。
异常处理是面向对象语言中很常见的特性,但是在日常开发过程中,经常发现很多开发人员要么重不使用异常,要么就简单粗暴的捕获一个通用异常替代所有异常。今天我们一起聊聊异常处理(这里我们以C++和C#的异常作为例子)。
上一篇文章我们介绍了右值和右值引用,以及C++11引入的移动语义和完美转移等概念。本文我们将继续讨论上一篇文章遗留的问题以及关于右值引用的一些具体应用实现。
自从C+11的出现,C++语言推出了很多新的特性,这些特性不仅提升了C++开发效率,而且还对C++98/03进行了一些语义的扩展。尤其是右值引用这个概念,在C++11中被大量使用,所以对右值和右值引用的正确理解是用好C++11的基础。今天我们就一起聊聊什么是右值和右值引用。