Ronnie@2019-CSDN博客

原创 DDD学习笔记

DDD（Domain-Driven Design，领域驱动设计）是一种将复杂的业务逻辑作为软件开发的核心，通过深入理解业务领域，构建高质量软件的方法论。整体上，DDD分为战略设计和战术设计两个层次。

2024-04-09 20:42:41 599

第9章高级用法9.1 行键设计9.1.1 概念HBase的表中的数据分割主要使用列族而不是列，这与一般的列式存储数据库的概念有所不同。右上角的图片展示了逻辑布局如何转换为实际的物理存储布局。每一行的单元格被有序存储，同时不同列族的数据存储在不同文件中。换句话说，磁盘上一个列族下所有的单元格都存储在一个存储文件（store file）中，不同列族的单元格不会出现在同一个存储文件中。因为HBase不存储任何在表中没有值的单元格（在RDBMS中，NULL可作为空值存储），磁盘文件中也只有这些已经有值

2021-06-07 20:19:40 249 2

原创《HBase权威指南》读书笔记（一）

第8章架构8.1 数据查找和传输8.1.1 B+树B树的一些特性使其能够通过主键对记录进行高效插入、査找以及删除。它表示为一个动态、多层并有上下界的索引。同时要注意维护每一段（也被称作页表）所包含的主键数目。分段B+树的效果远好于二叉树的数据划分，其大大减少了查询特定主键所需的IO操作。除此以外，B+树能够提供髙效的范围扫描功能，这得益于它的叶节点相互连接并且按主键有序，扫描时避免了耗时的遍历树操作。这也是B+树被关系型数据库用作索引的原因之一。如果要进行一次范围査询，则可能需要读取多个在磁盘

2021-06-07 15:29:46 293

原创《数据密集型应用系统设计》读书笔记——第三部分派生数据（二）

第11章流处理系统批处理系统有一个很大的假设：即输入是有界的，即已知和有限的⼤小，所以批处理知道它何时完成输⼊的读取。实际上，很多数据是⽆界限的，因为它随着时间的推移而逐渐到达：你的用户在昨天和今天产⽣了数据，明天他们将继续产⽣更多的数据。除非你停业，否则这个过程永远都不会结束，所以数据集从来就不会以任何有意义的⽅式“完成”。因此，批处理程序必须将数据⼈为地分成固定时间段的数据块，例如，在每天结束时处理理一天的数据，或者在每小时结束时处理一小时的数据。日常批处理中的问题是，输⼊的变更只会在⼀天之后

2021-05-02 00:57:27 1122

原创《微服务架构设计模式》阅读笔记（六）

第11章开发面向生产环境的微服务应用11.1 开发安全的服务为了开发安全的软件并远离头条新闻，企业需要解决各种安全问题，包括硬件的物理安全性、传输和静态数据加密、身份验证、访问授权以及修补软件漏洞的策略，等等。应用程序开发人员主要负责实现安全性的四个不同方面：身份验证：验证尝试访问应用程序的应用程序或人员（安全的术语叫主体）的身份。例如，应用程序通常会验证访问主体的凭据，例如用户的I和密码，或应用程序的AP密钥。访问授权：验证是否允许访问主体对指定数据完成请求的操作。应用程序通常使用基于角色的

2021-05-02 00:53:35 1850 1

原创《微服务架构设计模式》阅读笔记（五）

第9章微服务架构中的测试策略（上）测试通常都在开发完成后执行，并且一般都是手动执行的。这种测试方法现在不管用了，原因有两个：手动测试效率极低：你永远不应该让人类去做一台机器可以做得更好的事情。与机器相比，手动测试执行的速度很慢，不能全天候工作。如果依赖手动测试，你将无法快速且安全地交付高质量的软件。编写自动化测试至关重要。在交付流程中才进行测试为时已晚：在编写应用程序之后，确实应该通过测试来找出软件潜在的问题，但经验表明这些测试不够充分。一种更好的方式是让开发人员编写自动化测试，以此作为开发的一部

2021-04-30 09:02:20 216

原创《微服务架构设计模式》阅读笔记（四）

第7章在微服务架构中实现查询在微服务架构中实现查询操作有两种不同的模式：API组合模式：这是最简单的方式，应尽可能使用。它的工作原理是让拥有数据的服务的客户端负责调用服务端，应组合服务返回的查询结果。命令查询职责隔离（CQRS）模式：它比API组合模式更强大，但也更复杂。它维护一个或多个视图数据库，其唯一的目的是支持查询。7.1 使用API组合模式进行查询7.1.1 findOrder（）查询曹组偶findOrder（）操作通过主键检索订单。它将orderId作为参数并范围OrderDet

2021-04-27 09:22:12 991

原创《微服务架构设计模式》阅读笔记（三）

第5章微服务架构中的业务逻辑设计图5-1显示了一个典型的服务架构。业务逻辑是六边形架构的核心。业务逻辑的周围是入站和出站适配器。入站适配器处理来自客户端的请求并调用业务逻辑。出站适配器被业务逻辑调用，然后在调用其他服务和外部应用程序。业务逻辑通常是服务中最复杂的部分。在开发业务逻辑时必须做出的关键决策是选用面向对象的方式，还是面向过程的方式。组织业务逻辑主要有两种模式：面向过程的事务脚本模式和面向对象的领域建模模式。5.1.1 使用事务脚本设计业务逻辑事务脚本的一个重要特征是实现行为的类与存储状

2021-04-22 08:34:13 454 1

原创《微服务架构设计模式》阅读笔记（二）

第3章微服务架构中的进程通信3.1 微服务架构中的进程间通信概述3.1.1 交互方式有多种客户端和服务端的交互方式，他们可以分为两个维度。第一个维度关注的是一对一和一对多：一对一：每个客户端请求由一个服务实例来处理。一对多：每个客户端请求由多个服务实例来处理。交互方式的第二个维度关注的是同步和异步：同步模式：客户端请求需要服务端实时响应，客户端等待响应时可能导致堵塞。异步模式：客户端请求不会阻塞请求，服务端的响应可以是非实时的。一对一的交互方式有以下几种类型。请求/响应：一个

2021-04-15 09:10:15 828

原创分页设计问题梳理

常见分页形式在列表页实现分页展示逻辑是十分常见的需求，但针对不同的场景和产品需求，分页功能有不同的表现形式。常见的有如下几种。1、滚动翻页下滑自动下一页，展示直到当前页的所有内容，不显示总页数、总条数，不支持上一页、跳页，不支持page size设置2、上/下一页只支持简单的上/下一页的操作，不显示总页数、总条数，不支持跳页，不支持page size设置3、跳页（最为常见）支持上/下一页、跳页，page size固定，不显示总页数4、跳页、显示总页数支持上/下一页、跳页，page size

2021-04-11 23:59:04 1260

原创《微服务架构设计模式》阅读笔记（一）

第1章逃离单体地狱1.1 迈向单体地狱的漫长旅程1.1.1 FTGO应用程序的架构FTGO，即Food to GO公司，作者虚构出来的一家公司。图1-1是它的架构图。1.1.2 单体架构的好处应用开发很简单：IDE和其他开发工具只需要构建这一个单独的应用程序易于对应用程序进行大柜摸的更改：可以更改代码和数据库，然后构建和部署测试相对简单直观：开发者只需写几个端到端测试，启用应用程序，调用REST API部署简单明了：开发者唯一需要做的，就是把可执行文件复制到服务器上横向扩展毫不费力：

2021-03-26 09:26:06 2305 3

原创《领域驱动设计-软件核心复杂性应对之道》阅读笔记（四）

第四部分战略设计第14章保持模型的完整性14.1 模式:BOUNDED CONTEXT任何大型项目都会存在多个模型。而当基于不同模型的代码被组合到一起后，软件就会出现bug、变得不可靠和难以理解。团队成员之间的沟通变得混乱。人们往往弄不清楚一个模型不应该在哪个上下文中使用。模型混乱的问题最终会在代码不能正常运行时暴露出来，但问题的根源却在于团队的组织方式和成员的交流方法。因此，为了澄清模型的上下文，我们既要注意项目，也要注意它的最终产品(代码、数据库模式等)。一个模型只在一个上下文中使用。这

2021-03-11 22:43:30 3652

原创《领域驱动设计-软件核心复杂性应对之道》阅读笔记（三）

第三部分通过重构来加深理解第8章突破重构的投入与回报并非呈线性关系。通常，小的调整会带来小的回报，小的改进也会积少成多。小改进可防止系统退化，成为避免模型变得陈腐的第一道防线。但是，有些最重要的理解也会突然出现，给整个项目带来巨大的冲击。可以确定的是，项目团队会积累、消化知识，并将其转化成模型。微小的重构可能每次只涉及一个对象，在这里加上一个关联，在那里转移一项职责。然而，一系列微小的重构会逐渐汇聚成深层模型。一般来说，持续重构让事物逐步变得有序。代码和模型的每一次精化都让开发人员有了更加清晰

2021-03-10 00:00:04 995

原创《领域驱动设计-软件核心复杂性应对之道》阅读笔记（二）

第二部分模型驱动设计的构造块第4章分离领域

2021-02-27 23:28:15 1385

原创《领域驱动设计-软件核心复杂性应对之道》阅读笔记（一）

第一部分运用领域模型模型是一种简化，它是对现实的解释——把与解决问题密切相关的方面抽象出来，而忽略无关的细节。为了创建真正能为用户活动所用的软件，开发团队必须运用一整套与这些活动有关的知识体系，所需知识的广度可能令人望而生畏，庞大而复杂的信息也可能超乎想象。模型正是解决此类信息超载问题的工具。模型这种知识形式对知识进行了选择性的简化和有意的结构化。适当的模型可以使人理解信息的意义，并专注于问题。模型在领域驱动设计中的作用在领域驱动的设计中，3个基本用途决定了模型的选择。(1) 模型和设计的核心互

2021-02-10 08:17:57 505

原创《数据仓库》阅读笔记（二）

第7章主管信息系统和数据仓库7.1 EIS概述主管信息系统（Executives Information System）是计算的最有效形式之一。通过EIS，高级管理分析人员可以精确指出问题并发现对于管理至关重要的趋势。EIS处理是出于帮助主管指定决策而设计的。EIS的基本思想是提供信息，但不需要真正理解创建这些信息的基本结构。EIS的典型用途是：趋势分析和发现关键比例指标度量和跟踪向下钻取分析问题监控竞争分析关键性能指标监控7.2 一个简单的例子略~7.3 向下钻取分析向下钻

2021-02-06 21:50:22 2289

原创《数据仓库》阅读笔记（一）

第1章决策支持系统的发展（一）1.1 演化主要介绍数据仓库和决策支持系统（Decision Support System，DSS）处理的起源和演化过程。略~1.2 自然演化式体系将诶购物的问题自然演化式体系及诶狗带来了许多新的挑战，如：数据可信性生产率问题无法将数据转化为信息1.2.1 数据缺乏可信性数据缺乏可信性这种危机广泛存在，也是可以预见的。主要有如下五个原因：数据无时间基准对于在不同时刻抽取出来的任何数据集，如果它们的分析结果是相同的，那只能是偶然数据算法上的差异

2021-01-30 21:51:08 4724

原创《数据密集型应用系统设计》读书笔记——第二部分分布式数据系统（二）

第8章分布式系统的挑战故障与部分失效当你在⼀台计算机上编写一个程序时，它通常会以一种确定的方式运⾏：⽆论是⼯作还是不工作。充满错误的软件可能会让人觉得电脑有时候是“糟糕的一天”（这个问题通常是重新启动的问题），但这主要是软件写得不好的结果。单个计算机上的软件没有根本性的不可靠原因：当硬件正常⼯作时，相同的操作总是产⽣相同的结果（这是确定性的）。如果存在硬件问题（例如，内存损坏或连接器松动），其后果通常是整个系统故障（例如，内核崩溃，“蓝屏死机”，启动失败）。装有良好软件的个人计算机通常要么功能

2021-01-24 23:20:47 1504

原创 Redis主从复制

在redis中用户可以通过执行SLAVEOF命令或者设置配置文件中的slaveof选项，让一个redis服务器去复制另一个服务器，这种功能我们称之为redis的主从复制。被复制的服务器称为主服务器（master），复制主服务器的叫做从服务器（slave)。redis的主从复制功能分为同步和命令传播两个操作：同步：用于将从服务器的数据库状态更新至主服务器的当前数据库状态，保持主从服务的一致性；...

2021-01-17 16:51:33 182

原创《微服务设计》读书笔记

第1章微服务微服务定义微服务并没有准确的定义，一般，我们把一些协同工作的小而自治的服务称为微服务。通过这个约定俗称的定义，我们可以知道微服务的两大特点：1）小；2）自治小，专注做好一件事在传统的单体应用中，一个服务的代码量往往是非常庞大的，相似功能代码随处可见，给bug修复和新功能开发带来了很大的困难。为了保证内聚性，单体应用中会创建一些抽象层或者模块。但微服务直接将这个概念应用到了独立的服务上，根据业务边界来确定服务边界。由于该服务很好的专注于某个边界之内，因此可以很好的避免服务代码量的逐步增

2021-01-17 16:51:19 698

原创《基于Apache Flink的流处理》读书笔记

第1章状态化流处理概述传统数据处理绝大多数企业所实现的传统架构都会将数据处理分为两类：事务型处理分析型处理事务型处理企业在日常业务运营过程中会用到各类应用，例如：客户管理管理软件、基于Web的应用等，这些应用系统通常都会设置独立的数据处理层（应用程序本身）和数据存储层（事务型数据库系统）。这些应用通常会连接外部服务或实际用户，并持续处理诸如订单、邮件、网站点击等传入的数据。期间每处理一条事件，应用都会通过执行远程数据库系统的事务来读取或者更新状态，多个应用会共享同一个数据库系统，有时候还

2021-01-17 16:50:54 72494 1

原创《数据密集型应用系统设计》读书笔记——第一部分数据系统基础

第一部分数据系统基础第1章可靠、可扩展与可维护的应用系统当今许多新型应用都属于数据密集型，而不是计算密集型。对于这些类型应用，CPU的处理能力往往不是第一限制性因素，关键在于数据量、数据的复杂度以及数据的快速和多变性。数据密集型应用系统设计也是基于标准模块构建而成的，通常包含以下模块：数据库：用以存储数据，之后应用可以再次访问高速缓存：缓存那些复杂或操作代价高昂的结果，以加快下一次访问索引：用户可以按关键字搜索数据并支持各种过滤流式处理：持续发送消息至另外一个进程，处理通常采用异步方式

2021-01-17 16:50:25 3659

原创《数据密集型应用系统设计》读书笔记——第二部分分布式数据系统（一）