读数据工程之道：设计和构建坚固的数据系统08主要架构概念 ...

1. 域和服务

1.1. 域是你正在为其构建的实际天下主题地区
1.2. 服务是一组功能，其目标是完成一项使命
1.3. 一个域可以包含多个服务
1.4. 确定范畴中应包含的内容

• 1.4.1. 确定范畴应该包含什么以及要包括哪些服务时，最好的建议是简单地去与用户和利益相干者交谈，倾听他们在说什么，并构建将帮助他们完成工作的服务
  
• 1.4.2. 要避免在真空中进行架构设计的经典陷阱
  

2. 可扩展性

2.1. 答应我们增加系统的容量以进步性能和处理需求
2.2. 单台机器上可能的资源有硬性限制
3. 弹性

3.1. 一个可扩展系统动态扩展的能力
3.2. 一个高弹性的系统可以根据当前的工作负载主动扩容和缩容
3.3. 随着需求的增加，扩大规模至关重要，而缩小规模则可以在云环境中节省资金
3.4. 当代系统偶尔会缩放到零，这意味着它们可以在空闲时主动关闭
3.5. 动态缩放有助于在没有工程师手动干预的环境下确保富足的性能

• 3.5.1. 弹性进步可靠性
  

4. 可用性

4.1. IT服务或组件处于可利用状态的时间百分比
4.2. 单机通常无法提供高可用性和可靠性
5. 可靠性

5.1. 系统在指定时间隔断内执行其预期功能时满意规定标准的概率
5.2. 低可靠性会导致低可用性
6. 分布式系统

6.1. 使用分布式系统来实现更高的整体扩展能力以及更高的可用性和可靠性
6.2. 水平扩展答应你添加更多机器以满意负载和资源需求
6.3. 水平扩展系统有一个主节点，作为工作负载实例化、进度和完成的主要联系点
6.4. 典型的当代分布式架构也内置冗余
6.5. 分布式系统的管理细节通常被抽象出来，使你可以专注于高级架构而不是低层次管道
7. 紧耦合与松耦合

7.1. 紧耦合

• 7.1.1. 可以选择拥有较为会合的依赖项和工作流
  
• 7.1.2. 范畴和服务的每个部分都非常依赖于其他范畴和服务
  

7.2. 松耦合

• 7.2.1. 拥有分散的范畴和服务，它们彼此之间没有严格的依赖性
  
• 7.2.2. 在松耦合的环境下，分散的团队很容易构建其数据可能无法被同行使用的系统
  
• 7.2.3. 确保为拥有各自范畴和服务的团队分配共同的标准、所有权、责任和任务
  

7.3. 设计“好的”数据架构依赖于范畴和服务的紧耦合和松耦合之间的权衡
8. 架构层次

8.1. 单层

• 8.1.1. 在单层架构中，你的数据库和应用程序紧耦合，驻留在单个服务器上
  
• 8.1.2. 该服务器可以是你的笔记本电脑或云中的单个虚拟机(Virtual Machine，VM)
  
• 8.1.3. 紧耦合的性质意味着如果服务器、数据库或应用程序出现故障，则整个架构都会失败
  
• 8.1.4. 单层架构适用于原型设计和开发，但由于显着的故障风险，因此不建议将其用于生产环境
  
• 8.1.5. 单层架构适用于在本地计算机上测试系统，但不建议用于生产用途
  
• 8.1.6. 单层架构提供了简单性，但也有严峻的局限性
  

8.2. 多层

• 8.2.1. 通过解耦数据和应用程序解决了紧耦合单层架构的挑衅
  
• 8.2.2. 多层（也称为n层）架构由单独的层构成：数据、应用程序、业务逻辑、展示等
  
  
  
  • 8.2.2.1. 将数据与应用程序分离，并将应用程序与展示分开
    
  
  
• 8.2.3. 这些层是自底向上和分层的，这意味着下层不一定依赖于上层
  
  
  
  • 8.2.3.1. 上层依赖于下层
    
  
  
• 8.2.4. 三层架构由数据层、应用程序/逻辑层和表示层构成
  
  
  
  • 8.2.4.1. 每一层都相互隔离，答应关注点的分离
    
  • 8.2.4.2. 使用三层架构，你可以在每一层中自由使用你喜好的任何技术，而无须会合精力
    
  
  
• 8.2.5. 数据工程师应该使用层来评估他们的分层架构和处理依赖关系的方式
  
  
  
  • 8.2.5.1. 考虑你是否希望节点出现资源争用
               8.2.5.1.1. 如果不是，则使用无共享架构：单个节点处理每个请求，这意味着其他节点不与该节点或彼此共享内存、磁盘或CPU等资源
    
  • 8.2.5.2. 节点是否应该共享所有节点都可以访问的相同磁盘和内存
               8.2.5.2.1. 共享磁盘架构
    
  
  

8.3. 单体

• 8.3.1. 单体内部的耦合
  
  
  
  • 8.3.1.1. 技术耦合
               8.3.1.1.1. 技术耦合指的是架构层次
    
  • 8.3.1.2. 范畴耦合
               8.3.1.2.1. 范畴耦合指的是范畴之间耦合在一起的方式
    
  
  
• 8.3.2. 单体在技术和范畴之间具有差别程度的耦合
  
• 8.3.3. 单体的紧耦合意味着其组件缺乏模块化
  

8.4. 微服务

• 8.4.1. 微服务架构包括独立的、分散的和松耦合的服务
  
• 8.4.2. 每个服务都有一个特定的功能，并且与在其范畴内运行的其他服务解耦
  
• 8.4.3. 单体不是一蹴而就的，它是一个技术问题，也是一个组织问题
  

8.5. 注意事项

• 8.5.1. 中心数据堆栈本质上是庞大的
  
  
  
  • 8.5.1.1. 向与数据堆栈等效的微服务的转变是将拥有特定范畴数据管道的工作流连接到相应的特定范畴数据堆栈进行解耦
    
  
  
• 8.5.2. 务实地将使用松耦互助为一种抱负，同时认识到你在数据架构中使用的数据技术的状态和局限性
  
• 8.5.3. 以垂直方式将架构的组件分为差别的关注层
  
• 8.5.4. 会合化：一个团队负责从所有范畴网络数据并协调它以供整个组织使用
  
• 8.5.5. 数据网格
  
  
  
  • 8.5.5.1. 使用数据网格，每个软件团队负责准备其数据以供组织的其他部门使用
    
  
  
• 8.5.6. 单体不一定是坏的，在某些条件下从单体开始可能是有意义的
  
  
  
  • 8.5.6.1. 从单体开始要简单得多
    
  • 8.5.6.2. 准备好最终将其分解成更小的部分
    
  
  

9. 用户访问

9.1. 多租户

• 9.1.1. 所有云服务都是多租户的，尽管这种多租户出现在差别的粒度上
  
  
  
  • 9.1.1.1. 云计算实例通常位于共享服务器上，但虚拟机自己提供了一定程度的隔离
    
  • 9.1.1.2. 对象存储是一个多租户系统，但只要客户精确配置其权限，云供应商就可以包管安全性和隔离性
    
  
  
• 9.1.2. 工程师经常需要在更小的范围内做出有关多租户的决策
  
  
  
  • 9.1.2.1. 来自差别租户的数据必须得当隔离
    
  • 9.1.2.2. 数据隔离策略因系统而异
    
  • 9.1.2.3. 必须确保视图不会泄漏数据
    
  
  

10. 变乱驱动架构

10.1. 一个变乱驱动的工作流包含在数据工程生命周期的各个部分创建、更新和异步移动变乱的能力
10.2. 主要范畴

• 10.2.1. 变乱生产
  
• 10.2.2. 路由
  
• 10.2.3. 消耗
  

10.3. 变乱驱动架构的优势在于它将变乱的状态分布到多个服务中
11. 棕地项目

11.1. 棕地(Brownfield)项目通常涉及重构和重组现有架构，并受到现在和过去的选择的限制
11.2. 最好是深入发掘、提出问题并理解做出决策的原因
11.3. 同理心和上下文在帮助你诊断现有架构的问题、发现机会和辨认陷阱方面大有帮助
11.4. 直接重写的一种流行替代方法是绞杀者模式：新系统迟钝地、渐渐地更换遗留架构的组件
11.5. 如果你在一个大型组织中，根除遗留技术或架构可能是不可能的
12. 绿地项目

12.1. 绿地(Greenfield)项目让你开创一个全新的开始，不受先前架构的汗青或遗留问题的限制

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。