My Blogs
云原生十二要素
Published 2022年01月01日 08:00 by james
十二要素核心概念
十二要素(The Twelve Factors)是由Heroku团队提出的云应用设计理念，它为构建流程标准化和高可移植的SaaS应用提供了完善的方法论。遵循十二要素设计的应用具备云原生应用的所有特征。十二要素适用于任何语言开发的后端应用服务，它提供的方法论和核心思想如下:
- 将流程自动化和标准化，降低新员工的学习成本。
- 划清与底层操作系统间的界限，以保证最大的可移植性。
- 适合部署在现代云平台上，避免对服务器与操作系统进行管理。
- 将开发环境与生产环境的差异降至最低，便于实施持续交付和敏捷开发。
- 应用可以在不改变现有工具、架构或开发流程的情况下，方便地进行水平伸缩
十二要素重点关注应用程序的健康成长，开发者之间的有效代码协作，以及避免软件腐蚀。十二要素的内容如图所示:
在基础架构即服务(Infrastructure as a Service，IaaS)和平台即服务(Platform as …
谈谈对分布式系统原理的理解
Published 2021年12月12日 09:00 by james
TL;DR
分布式系统的三态:
成功、失败、超时(未知)
- 1 概念
- 1.1 模型
- 1.2 副本
- 1.3 衡量分布式系统的指标
- 2 分布式系统原理
- 2.1 数据分布方式
- 2.2 基本副本协议
- 2.3
Lease机制 - 2.4
Quorum机制 - 2.5 日志技术
- 2.6 …
编程范式
Published 2021年12月10日 12:10 by james
TL;DR
- 结构化编程是对程序控制权的直接转移的限制。
- 面向对象编程是对程序控制权的间接转移的限制。
- 函数式编程是对程序中赋值操作的限制。
一句话总结
- 结构化编程对程序控制权的直接转移进行了限制和规范。
- 面向对象编程对程序控制权的间接转移进行了限制和规范。
- 函数式编程对程序中的赋值进行了限制和规范。
如你所见，我在介绍三个编程范式的时候，有意采用了上面这种格式，目的是凸显每个编程范式的实际含义——它们都从某一方面限制和规范了程序员的能力。没有一个范式是增加新能力的。也就是说，每个编程范式的目的都是设置限制。这些范式主要是为了告诉我们不能做什么，而不是可以做什么。
另外，我们应该认识到，这三个编程范式分别限制了goto语句、函数指针和赋值语句的使用。那么除此之外，还有什么可以去除的吗？ 没有了。因此这三个编程范式可能是仅有的三个了——如果单论去除能力的编程范式的话。支撑这一结论的另外一个证据是，三个编程范式都是在1958年到1968年这10年间被提出来的，后续再也没有新的编程范式出现过。
编程范式与软件架构的关系
大家可能会问，这些编程范式的历史知识与软件架构有关系吗？ 当然有，而且关系相当密切。譬如说：
- 多态是我们跨越架构边界的手段，
- 函数式编程是我们规范和限制数据存放位置与访问权限的手段，
- 结构化编程则是各模块的算法实现基础。
这和软件架构的三大关注重点不谋而合: 功能性、组件独立性以及数据管理。
数据一致性解决方案
Published 2021年11月11日 18:00 by james
数据一致性理论
在介绍分布式系统的数据一致性问题之前，我们先来了解一下副本的概念。分布式系统会存在许多异常问题，例如机器死机、网络中断、高并发下I/O瓶颈、数据库存储空间不足等。为了提供高可用服务，一般会将数据或者服务部署到很多机器上，这些机器中的数据或服务可以称为副本。将数据复制成多份不仅可以增加存储系统高可用性，而且可以增加读操作的并发性，如果其中任何一台机器出现故障，用户可以访问其他机器上的数据或服务。如何保证这些节点上的副本数据或服务的一致性，是整个分布式系统需要解决的核心问题，也就是本章提到的数据一致性问题。一般来说，数据一致性可以分成三类: 时间点一致性、事务一致性、应用一致性。 1. 时间点一致性: 也叫作副本一致性，如果所有相关的数据副本在任意时刻都是一致的，那么可以称作时间点一致性。 2. 事务一致性: 是指在一个事务执行前和执行后数据库都必须处于一致性状态。如果事务成功完成，那么系统中所有变化将正确地应用，系统处于有效状态；如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。 3. 应用一致性: 事务一致性代表单一数据源或者狭义上的数据库；广义上的数据可能包括多个异构的数据源，比如数据源有多个数据库、消息队列、文件系统、缓存等，那么就需要应用一致性，这里也称作分布式事务一致性。
数据一致性是架构师在设计一个企业应用系统数据架构时必须考虑的一个重要问题，尤其在互联网分布式架构环境下，一个完整的业务被拆分到多个分布式的应用系统中，数据一致性的问题就显得尤为突出。分布式系统采用多机器分布式部署的方式提供服务，必然存在着数据的复制。在分布式系统引入复制机制后，由于网络延时等因素，不同的数据节点之间很容易产生数据不一致的情况。复制机制的目的是保证数据的一致性，但是复制数据面临的主要难题也是如何保证多个副本之间的数据一致性。
数据一致性模型
分布式系统一般通过复制数据来提高系统的可靠性和容错性，并且将数据的不同副本存放在不同的机器中。由于维护数据副本的一致性代价高，因此许多系统采用弱一致性来提高性能，一些不同的一致性模型也相继被提出。在CAP中，P(分区容错性)无法避免，A(可用性)是所有大型业务比较看重的，那么C(一致性)如何演变呢？按照不同的角度，一致性可以分为客户端和系统端。从客户端角度看，就是客户端读写操作是否符合某种特性；从系统端角度看，就是系统更新如何复制分布到整个系统，以确保数据最终一致。 如果从客户端角度看，一致性又可以分为以下3种。 1. 强一致性(strong consistency): 在任何时候，用户或节点都可以读到最近一次成功更新的副本数据。这种一致性肯定是我们最想要的，但是很遗憾，强一致性在实践中很难实现，而且一般会牺牲可用性。 2. 弱一致性(weak consistency): 某个进程更新了副本的数据，但是系统不能保证后续进程能够读取到最新的值。比如某些缓存、网络游戏、网络电话等系统。 3. 最终一致性(eventual consistency): 最终一致性是弱一致性的一种特例。A进程更新了副本的数据，如果没有其他进程更新这个副本的数据，系统最终一定能够保证在后续进程中能够读取到A进程写入的最新值。但是这个操作存在一个不一致的窗口，也就是从A进程写入数据到其他进程读取A所写数据所需的时间。根据更新数据后各进程访问数据的时间和方式的不同，最终一致性又可以分为以下5种。 - 因果一致性( …
函数式编程模式
Published 2021年11月08日 11:11 by james
模式词汇表1
替代面向对象模式
这一部分会向你展示如何采用函数式语言的特性来替代普通的面向对象模式。这样做通常可以减少我们需要编写的代码数量，从而让我们维护的代码变得更加简洁。
模式1 替代函数式接口
在这一模式中，我们采用原生的函数式特性来替代像Runnable或Comparator这样常见的函数式接口。
在这一部分中，我们引入了两个基本的函数式特性。
- 第一个特性是高阶函数(higher-order function)，它允许我们将函数作为头等数据进行传递。
- 第二个特性是匿名函数，它允许我们编写快捷的一次性函数，而无需为其指定函数名。
通过将这两个特性相结合，我们可以用一种非常简洁的方式来替代大多数的函数式接口实例。
模式2 替代承载状态的函数式接口
我们采用这种模式来替代那些需要承载某些状态信息的函数式接口实例，为此我们引入了一个新的特性: 闭包。闭包可以将某个函数和某些状态进行打包传递。
模式3 替代命令模式
替代命令模式将行为封装于某个对象之中。
在这一模式中，我们将了解如何使用在前两种模式中所介绍的技术来替代面向对象版本的命令模式。 …