领域驱动模型&CQRS学习
| 编辑推荐: |
| 本文来自于csdn，由火龙果软件Anna编辑、推荐。 |
我将通过一个web应用的架构设计来说明这些架构，web应用的基础架构搭建在AWS上，利用AWS提供的相应服务，可以设计出不同的高可用方案。
1. 最简单的三层架构：
这与传统非云架构的三层架构一致，没有分布式架构，只拥有一个单独的应用实例，单一的数据库。如下图，架构采用：
EC2
Amazon RDS
Route 53 DNS服务
S3 作为内容存储，数据备份该架构结构简单，使用的S3备份服务后已经具有一定的防灾，灾难恢复功能。这种架构AWS官方说明可以具有每年少于3天15小时的宕机时间。这对大多数商业应用是不满足要求的。但是在开发，测试环境中被广泛使用。
2. 多域高可用设计模式
该设计模式提高了应用的高可用指标，宕机时间达到少于每年8小时45分钟。该设计采用：
AWS MultiAZ
EC2提供计算服务
ELB 作为负载均衡，
ASG (Auto Scaling Group)管理实例增减，替换
RDS 数据库，采用两个AZ RDS区域，灾难切换通过ASG实现
应用被分为多个AZ 区，最前端是两个Reverse Proxy，之后的两个Web server，提供双活机制，增强可用性。
软件架构要支持双活机制的自动切换
软件架构要支持系统无缝升级，以及客户无感知的业务回滚
软件架构应具有系统监控模块，监控web http 200 状态。
S3 提供系统备份功能
该架构的可用性已经很高，适用于有高可用性要求，但容许短暂业务暂停。比如企业内部使用的，但重要性又是很高的企业级应用，以及客户数量不高的对外商业应用。
3. 面向客户的商业应用
面向客户的应用对高可用有很高的要求，这里提供的架构可以保证每年低于52分钟的宕机时间。这个架构看起来与上面的很相似，但是由双活办成3实例高可用，这就更大的保证了高可用性，在某个instance宕机后不会影响业务，应用通过监控组件，发现问题，自动替换有问题的虚机。设计系统时需要注意着几点：
将应用程序部署在3个域中，三个域相互隔离，每个域设计负载容量极限不是整个系统的三分之一，而是50%容量
对于可以被缓存的内容，添加CloudFront以减少系统负载
在所有层中实现软件/应用程序弹性模式
需要实现自动部署，系统支持自动回滚，以实现系统出现故障是快速回复。
系统必须包括监控组件，用于监控系统，汇报问题。
4. 多物理区域部署方案
良好的应用以及基础架构设计可以很好的提高系统的高可用性，甚至达到每年52分钟的最小宕机时间。如果需要继续提高商业引用的高可用，就需要考虑多物理区域部署的方案，该方案通过夸物理区域的部署，避免单区域灾难的冲击。
跨物理区域方案具体设计为：
设计两个物理区域部署应用，两个区域设计为主、备，热备份的关系。
被动站点按比例缩小，最终保持一致，以获得与活动站点相同的流量。
两个区域都应保持静态稳定，以处理所有能力要求，即使是在一个AZ区故障期间。
在所有层中实现应用组件的弹性模式。
将需要一个轻量应用组件来监测应用程序的健康状况和区域依赖性。
静态网站在系统中扮演重要角色，其不但用于缓解高并发的情况，同时在故障转移期间，请求将被路由到静态网站，用以实现无缝迁移。
软件更新将使用蓝绿部署方法或者是Canary部署方法
该架构可以保证每年4小时以下的宕机时间，虽然不如上面提到的单物理节点商业级应用，但是因为其多物理区域的特点，许多银行，金融企业使用该架构。
5. 最高端的高可用应用架构
最高端的高可用架构可以保证每年少于5分钟以下的宕机时间，提供99.999%的高可用，可以说是高可用上的战斗机。重要的银行，金融，政府，军队部门都采用这样的架构。
高性能的存储解决方案，
架构中的每一层中采用冗余方案
在可能的情况下使用NoSQL数据库
采用主动/主动的多区域方法。每个区域都必须是静态稳定的
路由层将向健康站点发送流量，并在故障期间停止复制
在所有层中实现应用组件的弹性功能
需要一个轻量应用组件来监测应用程序的健康状况和区域依赖性。
静态网站在系统中扮演重要角色，其不但用于缓解高并发的情况，同时在故障转移期间，请求将被路由到静态网站，用以实现无缝迁移。
软件更新将使用蓝绿部署方法或者是Canary部署方法————————————————
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
