学习总结-Part1
2020-02-15 22:05:04 0 举报AI智能生成
容器化.NET应用架构指南-学习笔记-脑图-Part1
作者其他创作
大纲/内容
容器和Docker简介
容器化与容器
容器化类似于集装箱，可以通过船、火车或飞机来运输，而无需关心货物的内部情况，充当了软件标准单元的角色
容器最重要的优势是：实现了开发和运维之间的隔离
Docker
一个开源项目，旨在通过为应用程序打包为容器，实现应用的自动化部署
社区版（CE）
企业版（EE）
Docker容器与虚拟机的对比
依赖度
虚拟机需要依赖完整的GuestOS，比容器化需要更多的资源
容器只包含应用程序及其依赖，并以独立进程运行在主机OS上
隔离性
多容器运行在同一OS内核（共享内核），隔离性不如虚拟机高
Docker术语
容器镜像（Container Image）
容器（Container）
标签（Tag）
Dockerfile
构建（Build）
仓库（Repository，Repo）
注册表（Registry）
Docker Hub
Compose
编排引擎（Orchestrator）
为Docker容器选择.NET/.NET Core
应用.NET Core和容器的场景
需要跨平台 => Linux容器和Windows容器
应用程序架构是基于微服务的
需要容器快速启动且尽量保持轻量级已获得更高“密度”
应用.NET Framework和容器的场景
应用程序目前使用了.NET Framework并且高度依赖于Windows
需要使用.NET Core不支持的Windows API
需要使用.NET Core不支持的第三方.NET库或NuGet包
基于容器和微服务的应用架构
容器化部署模式
单体式方法：主机里运行多个应用，每个应用以一个容器的方式运行
多主机扩展单一容器
微服务架构
方法论
一种以小型服务集合来创建服务端应用的方法
每个服务在独立进程中运行，通过通信协议彼此通信
每个服务负责实现一个特定的端到端领域或有确定边界的业务逻辑，且每个服务独立开发和部署
每个服务拥有自己特定的领域数据模型和领域逻辑，基于不同数据存储技术（SQL&NoSQL）和不同编程语言实现的
开发重点
低耦合，独立开发、部署和扩展每个服务
优势
敏捷性
可维护性
易扩展性
数据自治
微服务架构重要原则
每个微服务必须拥有领域逻辑和数据
eg.客户实体存在多个服务但却隶属于不同上下文边界
源自领域驱动设计（DDD）中的限界上下文的概念
混合数据持久化
不同微服务通常使用不同种类的数据库，比如混合使用SQL和NoSQL数据库
具有服务的松散耦合、更好的性能、扩展性、更低成本和可管理型等
也带来了一些分布式数据管理的挑战
微服务与限界上下文
微服务理论源自于领域驱动设计（DDD）的限界上下文（BC）模式
微服务与限界上下文类似，但是强调分布式和独立部署，限界上下文并没有明确简单逻辑边界
为每个限界上下文定义一个服务是一个很好的开始，但没必要局限于此
逻辑架构和物理架构
创建微服务并不要求使用某种技术（例如Docker容器技术就不是必须的），微服务是一种逻辑架构
即使微服务能够独立运行于进程或容器（例如每个微服务单独的Docker容器就不是必须的），但也不是必要的
分布式数据管理的挑战
如何定义微服务边界
关注应用的逻辑领域模型和相关数据
基于上下文提供的限界上下文来设计微服务
如何创建从多个微服务获取数据的查询
API网关
CQRS 查询/读取表
中心数据库的“冷数据”
如何在多个微服务间实现一致性
CAP定理
事件驱动通信和发布订阅模式来实现最终一致性
如何在多个微服务间通信
减少使用跨服务的链式请求
基于消息或事件的异步通信
异步消息通信
单接收者消息通信
针对明确异步命令，基于消息的通信
多接收者消息通信
微服务通过基于事件驱动异步通信实现最终一致性
编排搞扩展和高可用的多容器服务
集群和编排引擎
Azure Service Fabric
Kubernetes
Docker Swarm
Mesosophere DC/OS
调度器
0 条评论
下一页
