传统单体架构与微服务架构
- 复杂度可控：将应用分解为一个个微小应用，规避了无止境的复杂度累计
- 可独立部署：每个微服务具备独立运行的进程，所以都可以独立部署
- 技术选型灵活
- 易于容错
- 易于扩展
- 功能特定
- 功能特定
微服务架构的不足
1.开发人员必须处理创建分布式系统的复杂性
- 开发工具是面向构建传统的单体应用程序的，不为开发分布式应用程序提供全面功能上的支持
- 测试更加困难。在微服务架构中，服务数量众多，每个服务都是独立的业务单元，服务主要通过接口进行交互，如何保证依赖的正常，是测试面临的主要挑战。
- 开发人员必须实现服务之间的通信机制
- 实现用例跨多个服务时，需要面对使用分布式事务管理的困难
- 实现阔多个服务的用例，需要团队之间进行仔细的协调
2.部署的复杂性
3.增加内存的消耗
微服务与SOA之间的区别
软件架构的4+1视图
微服务架构的中间通信
1.交互方式
- 1.一对一：每个客户端请求由一个服务实例来处理
- 2.一对多：每个客户端请求由多个服务实例来处理
- 1.同步模式：客户端请求需要服务端实时响应，客户端等待响应时可能导致堵塞
- 2。异步模式：客户端请求不会阻塞进程，服务端的响应可以是非实时的
一对一的交互类型：
- 1.请求/响应：一个客户端向服务端发起请求，等待响应，客户端期望服务端很快就会发送响应，在一个基于线程的应用中，等待过程可能造成线程阻塞，这样的方式会导致服务的紧耦合。
- 2.异步请求/响应，客户端发送请求到服务端，服务端异步响应请求，不会发生阻塞进程，因为五福短不会立即反应。
- 3.单向通知：客户端的请求发送到服务端，但是不期望服务端做出任何响应。
一对多的交互方式：
- 1.发布/订阅方式：客户端发布通知消息，被零个或多个感兴趣的服务订阅
- 2.发布/异步响应方式:客户端发布请求消息，然后等待从感兴趣的服务发回的响应
REST架构六大原则
1.C-S架构
数据存储在Server端，Client端只需使用就行。两端彻底分离的好处使client端代码的可移植性变强，Server端的拓展性变强。两端单独开发，互不干扰。
2.无状态
http请求本身就是无状态的。基于C-S架构，客户端的每一次请求带有充分的信息能够让服务端识别。请求所需的一些信息都包含在URL的查询参数、header、body，服务端能够根据请求的各种参数，无需保存客户端的状态，将响应正确返回给客户端。无状态的特征大大提高的服务端的健壮性和可拓展性。当然这种无状态性的约束也是有缺点的，客户端的每一次请求都必须带上相同重复的信息确定自己的身份和状态（这也是必须的），造成传输数据的冗余性，但这种确定对于性能和使用来说，几乎是忽略不计的。
3.统一格式
REST架构的核心，统一的接口对于REST服务非常重要。客户端只需要关注实现的接口即可。接口的可读性加强，使用人员方便调用。
4.一致的数据格式
服务端返回的数据格式要么是XML、要么是JSON，或者直接返回状态码。
5.系统分层
客户端通常无法表明自己是直接还是间接与端服务器进行连接，分层时同样要考虑安全策略。
6.可缓存
在万维网上，客户端可以缓存页面的响应内容。因此响应都应隐式或显式的定义为可缓存的，若不可缓存则要避免客户端在多次请求后用旧数据或脏数据来响应。管理得当的缓存会部分地或完全地除去客户端和服务端之间的交互，进一步改善性能和延展性
scale cube
X轴扩展：使用负载均衡器后运行的多份拷贝，简而言之就是一个Nginx后面挂载多台Tomcat，每台Tomcat就是一个相同的单体应用的拷贝，保证了单一节点失效下的高可用性，但是没有解决单体服务开发和维护复杂的问题。
Y轴扩展：将应用划分成了多个不同的服务，每个服务负责一个或多个紧密相关的功能。一般也被称为业务扩展或垂直拓展。
Z轴扩展：类似于X轴扩展，但是不同的是数据集的划分不同，每个服务器只负责处理整体数据的一个子集，系统的最前端有一个带状态的分布器，负责将请求路由到合适的服务器上。
发展历程
API网关的逻辑架构
统一对外接口：当用户需要集成不同产品或服务之间的功能，调用不同服务提供的功能时，通过APi网关可以让用户在不感知服务边缘的情况下，利用统一的接口组装服务。
统一鉴权：通过API网关对访问进行统一鉴权，不需要每个应用单独对调用方进行鉴权，应用可以专注于业务。
服务注册与授权：控制调用方，使其明确可以使用和不可以使用的服务。
服务限流：对调用每个接口的每日次数及总次数进行限制
全链路跟踪：通过API网关提供的唯一请求ID可以监控调用流程，以及调用的响应时间。
微服务架构设计原则
业务架构
产品经理和运营人员主要负责
逻辑架构
1.聚合微服务设计模式：沿X轴或者Z轴独立扩展，业务每个服务都用自己独立的缓存和数据库
2.代理微服务设计模式：聚合模式的一个变种，客户端不负责数据集合，只会按业务需求的差别调用不同的微服务。
3.链式微服务设计模式：缺点服务使用同步通信模式，在整个链式调用完成之前，客户端会一直堵塞，链路过长，会导致客户端请求超时。
4.分支微服务设计模式：聚合模式的扩展，允许同时调用两个微服务链
5.数据共享微服务设计模式：在单体应用到微服务架构的过渡阶段，可以使用数据共享微服务设计模式，部分微服务可能会共享缓存和数据库存储，不过只有在两个服务之间存在强耦合关系时才可以，对于基于微服务的新建应用而言，严禁使用这个模式来组织服务
6.异步消息传递微服务设计模式：REST是基于同步机制的，会造成调用链阻塞，使用消息队列代替REST请求/响应。
技术架构
技术架构简单的来说就是业务代码架构+业务数据设计+各种中间件+各种技术框架
胶水代码：用来将服务与单体应用集成起来，胶水代码可以通过以下三种方式访问单体应用中的数据
通过调用单体应用提供的远程API
直接访问单体应用的数据库
保存一份数据副本，和单体数据库保存同步。
基础架构
微服务中的技术选型
Dubbo
Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成
服务器负责启动，加载，运行提供者
提供者在启动时向注册中心注册自己提供的服务
消费者其中是向注册中心订阅自己所需的服务
注册中心返回提供者地址列表给消费者，如果有变更，注册中心将基于TCP长连接推送变更数据给消费者。
消费者从远程结构中调用远程接口，Dubbo会基于负载均衡算法选取一个提供者进行调用，如果调用失败就换一个
消费者和提供者在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心，可以在Dubbo的可视化界面上看到。
Dubbo中的默认负载均衡算法
1.Random LoadBalance:随机，按权重设置随机概率。 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后分布也比较均匀，有利于动态调整提供者权重。
2.RoundRobin LoadBalance：轮循，按每台机器相应速度的权重设置轮循比率。 存在慢提供者累积请求的问题，比如，某台机器因自身性能问题导致响应很慢，但没有故障，当请求调到这台机器时就会卡住，久而久之，所有的请求都会卡在这台机器上。
LeastActive LoadBalance：最少活跃调用数。 根据不同服务生产者的当前调用数统计分发，可以使当前连接数较多的提供者收到更少的请求，而使当前连接数较少的提供者优先收到更多的的请求。
ConsistentHash LoadBalance：一致性Hash，相同参数的请求总是会发送到同一提供者处。 当某一台提供者机器发生故障时，原本发往该提供者的请求会基于虚拟节点平摊到其他提供者处，不会引起剧烈变动。
现有Dubbo来实现微服务缺少的功能：
分布式配置：要配合DiamondX，Disconf，Apollo来实现
服务跟踪：可以使用Pinpoint，CAT，Zipkin来实现
批量任务：可以使用开源的Elastic-job来实现
Dubbo本身RPC框架的缺失：
服务提供方与调用方的接口依赖性太强
服务对平台敏感，难以简单复用
Spring Cloud
太强了的全家桶，后面再单独学
配置中心
主流的配置中心性能对比
请求链路追踪
请求链路追踪(Link Tracking)或者又叫应用性能管理(APM,Application performance Management)，主要用于在分布式系统中实现细颗粒度的请求链追踪和监控。
主流的APM性能对比
Service Mesh
应该具有的基本特征：
是一种基础设施层服务，服务间的通信通过服务网格进行
可靠地传输复杂拓扑中服务的请求，将它们变成现代的云原生服务
是一种网络代理的实现，通常与业务服务部署在一起，业务服务感知不到
是一种网络模型，位于TCP/IP之上的抽象层，TCP/IP负责在网络节点间可靠的传递字节码，Service Mesh则负责在服务间可靠地传输服务间的协议请求
可对运行时进行控制，是服务变得可监控，可管理