传统的web开发方式（单体应用模型）优缺点：
单体应用模型的优点：
开发简单 集中管理
基本不会重复开发
功能都在本地，没有分布式的管理和调用的消耗
单体应用模型的缺点：
1.单体应用程序随着时间的推移 会变得的越来越庞大 复杂 臃肿 使得开发人员正确修复bug和实现新功能变得非常困难和耗时；
单体应用程序越大 程序启动时间就越长，将会限制程序员的生产力，这也会减缓应用程序规模的发展；
对于单体应用程序来说，每一次的变更产生的影响都是不明确的须做大量的手工测试，这使得单体应用的持续部署无法实现；
4.单体应用程序的所有模块都部署在一起，当不同模块的资源产生冲突时，单体应用难以扩展；
单体应用程序的所有模块都运行在同一进程中，该应用实体都是相同的，一旦任何一个模块发生bug 如内存泄漏，都会影响整个应用的可用性；
单体应用程序使得采用新框架和语言变得非常的困难（时间和成本），这对于采用新技术是一个非常大的障碍；
巨大的单体应用程序如果存在的话 只有少数开发人员能够理解，因为使用了过时的 非生产技术编写，使得招聘新的优秀的开发人员变得困难；
-- >
因此实现敏捷开发和应用交付是不可能的。
==============================================================
微服务是如何解决复杂问题的？
微服务体系结构模式有许多重要的好处。
【高可用 高并发 高性能】
1. 它解决了复杂性的问题。
它将原本庞大的单一应用程序分解为一组服务。虽然功能总量没有改变，但应用程序已经被分成可管理的块或服务。每个服务都有一个以RPC或消息驱动API形式定义好的边界。微服务体系结构模式强制实现了某种程度的模块化，而在实践中，使用单块代码库很难实现这种模块化。因此，单个服务的开发要快得多，也更容易理解和维护。
2. 此体系结构允许专注于该服务的团队独立开发每个服务。
开发人员可以自由选择任何有意义的技术，只要服务遵守API契约
3. 微服务体系结构模式允许独立部署每个微服务。
开发人员从来不需要协调服务本地更改的部署。这些更改一经测试就可以部署。例如，UI团队可以执行A/B测试，并快速迭代UI更改。微服务体系结构模式使持续部署成为可能。
4. 微服务体系结构模式允许独立地伸缩每个服务。您可以只部署满足其容量和可用性约束的每个服务的实例数量.
微服务体系结构模式的弊端。
1. 微服务应用程序是一个分布式系统，这一事实带来了复杂性。
开发人员需要选择并实现基于消息传递或RPC的进程间通信机制。此外，它们还必须编写代码来处理部分故障，因为请求的目的地可能很慢或不可用。
2. 微服务的另一个挑战是分区数据库体系结构。
更新多个业务实体的业务事务相当常见。这些类型的事务在单片应用程序中实现起来很简单，因为只有一个数据库。然而，在基于微服务的应用程序中，您需要更新由不同服务拥有的多个数据库。
3. 测试微服务应用程序也要复杂得多。
例如，使用诸如Spring Boot这样的现代框架，编写一个测试类来启动一个独立的web应用程序并测试其REST API非常简单。相反，服务的类似测试类将需要启动该服务及其依赖的任何服务(或至少为这些服务配置存根)。
4. 微服务体系结构模式的另一个主要挑战是实现跨多个服务的更改。
例如，假设您正在实现一个需要更改服务a、B和C的故事，其中a依赖于B, B依赖于C。相反，在微服务体系结构模式中，您需要仔细计划和协调对每个服务的更改的推出。例如，您需要更新服务C，然后是服务B，最后是服务a。幸运的是，大多数更改通常只影响一个服务，而需要协调的多服务更改相对较少。
5. 部署基于微服务的应用程序也要复杂得多。
总之:
单一架构只适用于简单、轻量级的应用程序。如果将其用于复杂的应用程序，那么会是很痛苦的。
微服务体系结构模式对于复杂的、不断发展的应用程序是更好的选择，尽管它有缺点和实现方面的挑战。
==============================================================
云时代：
CAP定理 ：
====================================================================
微服务框架的概念：
系统架构需要遵循的三个原则
微服务架构：
API Gateway （网管服务）
【1. 提供统一的服务入口 让微服务对前端透明】
【 2. 聚合后台服务 节省流量 提升性能】
【3. 提供 安全 过滤 流控的API管理功能】
====================================================================
所有的微服务都是独立的java进程跑在虚拟机上，服务之间的通信（IPC） 通用的两种方式： 同步调用 和异步调用
同步调用
异步调用
====================================================================
：基于服务端的服务注册与发现（Zookeeper）
：基于客户端的服务注册与发现（Zookeeper）
====================================================================
微服务架构下的服务器挂了怎么办？
重试机制
限流
3.熔断机制
负载均衡
降级（本地缓存）
数据库系统oracle/mysql/sqlserver…、
缓存系统redis/mongo/memcache…、
分布式协调系统zookeeper
====================================================================
分布式锁要解决的问题：
分布式锁应该具备哪些条件？
Zookeeper框架 完美实现了分布式锁应该具备的六大条件。
Zookeeper框架的概念和实现分布式锁的步骤：
单点故障的概念：
分布式系统中通常采用主从模式，即一个主控机连接多个处理节点，主节点负责负责分发任务，从节点负责解决任务；当主节点发生故障时，整个系统就瘫痪了。这种故障就叫单点故障。
分布式锁服务
为了解决单点故障 --> Zookeeper框架（是分布式锁的实现）
====================================================================
微服务架构要考虑的问题：
聚合微服务设计模式（最常用的）
代理微服务设计模式
链式微服务设计模式
分支式微服务设计模式
数据共享微服务设计模式
异步消息传递微服务设计模式（重要）
