浅谈一下架构设计思路

四个原则：
三个要点：
pattern:
举个列子：

四个原则:
1./01 架构是不断演进的/,演进思维
2.分之思维：
系统和消息通讯
3.可用性
4.用领域思维建模
领域模型是对业务模型的抽象，DDD是把业务模型翻译成系统架构设计的一种方式。
区别 充血模型（DDD开发方式下 贫血模型（传统OOP开发方式下）
编码方式 以领域对象为主的行为状态转换 事务脚本（CRUD、判断、循环、检查等逻辑只是简单的方法级别拆分）
Service 跨领域逻辑的组合 事务脚本的对外包装
Domain 一个领域的entity集合包 VO/DTO
Entity 包含了一个领域里的状态、以及对状态的直接操作单元，具有自闭环的对象。 VO/DTO
ValueObject 简单的基本值对象，如电话号码、地址等，组成entity的基本单元 语言基本类型
Aggregation （有点类似数学中集合的定义）将实体和值对象划分为聚合并围绕着聚合定义边界。 多个VO/DTO
Aggregation Root 唯一可以给外界作为某个Aggregation引用的entity。

三个要点:
高性能，高扩展，高可用 设计系统架构：

Pattern:
高性能:
一.高性能数据库集群(读写分离,分库分表)
二.高性能NoSQL
K-V 存储：解决关系数据库无法存储数据结构的问题
列式数据库：解决关系数据库大数据场景下的 I/O 问题
三.高性能负载均衡
3.1.1 DNS 负载均衡
3.1.3 软件负载均衡

高扩展：
垂直扩容和水平扩容
垂直：对服务器本身进行更换，部署比以前更好的服务器。新的服务器相比以前的服务器有更快的CPU,更多的内存，更大更快的硬盘，更快的内存总线
水平扩容：部署更多的服务器，增加的服务器性能与之前的服务器性能相同，或者花费同样的费用

任务并行化：
任务可以分配到不同的机器上
分陪单独的任务在一个CPU的不同线程上

三、高可用 常见的架构方案
主备架构，只有主库提供读写服务，备库冗余作故障转移用

方案二：双主架构，两个主库同时提供服务，负载均衡

第二，主键冲突问题，ID统一地由分布式ID生成服务来生成可解决问题。

方案三：主从架构，一主多从，读写分离

四、 容灾方案
机房内容灾、同城容灾，还是跨城容灾，都是基于 MySQL 的无损半同步复制。

参考资料和推荐阅读：
https://blog.csdn.net/baiye_xing/article/details/124081653
https://baijiahao.baidu.com/s?id=1713398011203790925&wfr=spider&for=pc