1.架构复杂性来源.md
高并发
高可用
从代码角度，要注意隔离，超时重试，容错
从流程来说，单元测试，功能测试，性能测试，压力测试，发布需要灰度发布，都不可少
从监控的角度，指标化，自动化，智能化
从系统角度：
* 事前（负载均衡，集群策略，RAID，自动伸缩，任务分配，计算高可用，存储高可用）
* 事中（限流、降级、熔断）
* 事后（可回滚，切流）
从人的角度：
* 运维工具化，流程话，实在不行双人作业
* 安全防护
从自然的角度：
* 异地多活
阿里在整个高可用上也经历过了一段时间，主要是做了三个步骤。第一个是做了同城的双活，第二个做了异地只读及冷备，第三个是做了异地多活，经历了三代体系的演进才走到了今天。
业务设计原则
低成本、规模、安全
兼容性
经常有人把向前兼容和向后兼容混淆了。其实，这主要是由于中英文化差异引起的。
向前兼容的英文为 Forwards Compatibility，Forward有“将来”的含义。因此向前兼容就是指：以前的版本支持现在版本生成的数据，现在的版本支持以后的版本数据。比如你的CD盘可以放在CD光驱播放，也可以放在DVD光驱播放。
向后兼容的英文为Backwards Compatibility，Backward有“回头”的意思。所以向后兼容就是指现在的版本可以支持以前的版本数据。比如你的PC的DVD光驱也可以播放CD盘。
2.架构设计原则.md
CAP,BASE
SOLID
面向对象设计的原则
| 定义 | 参数 | 描述 |
|---|---|---|
| SRP | The Single Responsibility Principle | 单一职责原则 |
| OCP | The Open Closed Principle | 开放封闭原则 |
| LSP | The Liskov Substitution Principle | 里氏替换原则 |
| ISP | The Interface Segregation Principle | 接口分离原则 |
| DIP | The Dependency Inversion Principle | 依赖倒置原则 |
得墨忒耳定律
得墨忒耳定律（Law of Demeter，缩写LoD）亦称为“最少知识原则（Principle of Least Knowledge）”，是一种软件开发的设计指导原则，特别是面向对象的程序设计。得墨忒耳定律是松耦合的一种具体案例。该原则是美国东北大学在1987年末在发明的，可以简单地以下面任一种方式总结:
每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；
每个单元只能和它的朋友交谈：不能和陌生单元交谈；
只和自己直接的朋友交谈。
这个原理的名称来源于希腊神话中的农业女神，孤独的得墨忒耳。
很多面向对象程序设计语言用"."表示对象的域的解析算符，因此得墨忒耳定律可以简单地陈述为“只使用一个.算符”。因此，a.b.Method()违反了此定律，而a.Method()不违反此定律。一个简单例子是，人可以命令一条狗行走（walk），但是不应该直接指挥狗的腿行走，应该由狗去指挥控制它的腿如何行走。
STAR
所谓STAR原则，即Situation（情景）、Task（任务）、Action（行动）和Result（结果）四个英文单词的首字母组合。STAR原则是结构化面试当中非常重要的一个理论
DDD
Eric Evans的“Domain-Driven Design领域驱动设计”简称DDD，Evans DDD是一套综合软件系统分析和设计的面向对象建模方法
DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。
六边形架构和DDD最为契合，见下图：
六边形架构并非创造一种新的架构风格，只是将原来的分层架构风格重新解读，使得架构更加简洁通用。同时，在DDD的设计思想下，六边形架构风格，让领域模型处于架构的核心区域，让开发人员将焦点聚集到领域。DDD和六边形架构是天然契合的，是DDD的首选架构。
CQRS
CQRS——Cammand-Query Responsibility Segregation的缩写。翻译过来就是“命令与查询职责分离”。
简而言之，CQRS就是平常大家在讲的读写分离，通常读写分离的目的是为了提高查询性能，同时达到读/写的解耦。让DDD和CQRS结合，我们可以分别对读和写建模，查询模型通常是一种非规范化数据模型，它并不反映领域行为，只是用于数据显示；命令模型执行领域行为，且在领域行为执行完成后，想办法通知到查询模型。
REST
REST——即Representational State Transfer的缩写，翻译过来是"表现层状态转化"。参考至：理解RESTful架构。
RESTful风格的架构将‘资源’放在第一位，每个‘资源’都有一个URI与之对应，可以将‘资源’看着是ddd中的实体；RESTful采用具有自描述功能的消息实现无状态通信，提高系统的可用性；至于‘资源’的哪些属性可以公开出去，针对‘资源’的操作，RESTful使用HTTP协议的已有方法来实现：GET、PUT、POST和DELETE。