随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此 也不断的演进、升级、迭代。 从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构。
集中式架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本，此时，用于简 化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
- 存在问题：
- 代码耦合，开发维护困难
- 无法针对不同模块进行针对性优化
- 无法水平扩展
- 单点容错率低，并发能力差
垂直拆分
当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能 对系统进行拆分
- 优点
- 系统拆分实现流量分流，解决了并发问题
- 可针对不同模块进行优化
- 方便水平扩展，负载均衡，容错率提高
- 缺点
- 系统间相互独立，有很多重复工作，影响开发效率
分布式服务
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定 的服务中心， 使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。
分布式：将不同的业务模块部署到不同服务器上，每个模块各种独立，单独部署（SOA架构）
- 优点
- 将基础服务进行抽取，系统间相互调用，提高了代码复用和开发效率
- 缺点
- 系统间耦合变高，调用关系错综复杂，难以维护
服务治理
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问 压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键
- 以前出现了什么问题？ ·
- 服务越来越多，需要管理每个服务的地址 ·
- 调用关系错综复杂，难以理清依赖关系 ·
- 服务过多，服务状态难以管理，无法根据服务情况动态管理
- 服务治理要做什么？
- 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
- 服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系 ·
- 动态监控服务状态监控报告，人为控制服务状态
- 缺点：
- 服务间会有依赖关系，一旦某个环节出错会影响较大
- 服务关系复杂，运维、测试部署困难，不符合DevOps（开发部署等一体化）思想
微服务概述
微服务
相对于分布式，粒度更细，完全都可以单独部署，独立运行。
微服务与微服务机构
微服务是一种架构模式或者一种架构风格，提倡将单一应用程序划分成一组小的服务独立部署，服务之 间相互配合、相互协调，每个服务运行于自己的进程中。 服务与服务间采用轻量级通讯，如HTTP的RESTful API等 避免统一的、集中式的服务管理机制
微服务的优缺点
- 优点
- 每个服务足够内聚，足够小，比较容易聚焦
- 开发简单且效率高，一个服务只做一件事情
- 开发团队小，一般2-5人足以（当然按实际为准）
- 微服务是松耦合的，无论开发还是部署都可以独立完成
- 微服务能用不同的语言开发
- 易于和第三方集成，微服务允许容易且灵活的自动集成部署（持续集成工具有 Jenkins,Hudson,bamboo等）
- 微服务易于被开发人员理解，修改和维护，这样可以使小团队更加关注自己的工作成果，而无需一 定要通过合作才能体现价值
- 微服务允许你融合最新的技术
- 微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面组件融合。
- 每个微服务都可以有自己的存储能力，数据库可自有也可以统一，十分灵活。
- 缺点
- 开发人员要处理分布式系统的复杂性
- 多服务运维难度，随着服务的增加，运维的压力也会增大
- 依赖系统部署
- 服务间通讯的成本
- 数据的一致性
- 系统集成测试
- 性能监控的难度
调用方式介绍
无论是微服务还是SOA，都面临着服务间的远程调用。
- 常见远程调用
- RPC：Remote Produce Call远程过程调用，类似的还有RMI(Remote Method Invocation，远程 方法调用)。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门 的dubbo，都是RPC的典型
- HTTP：：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服 务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。现在热门 的Rest风格，就可以通过http协议来实现。
认识RPC
概念
RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。 该协议允许运行于一台 计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。 说得通俗一点就是：A计算机提供一个服务，B计算机可以像调用本地服务那样调用A计算机的服务。
作用体现
- 实现RPC主要是做到两点：
- 实现远程调用其他计算机的服务
- 像调用本地服务一样调用远程服务
认识HTTP
概念
Http协议：超文本传输协议，是一种应用层协议。规定了网络传输的请求格式、响应格式、资源定位和 操作的方式等。但是底层采用什么网络传输协议，并没有规定，不过现在都是采用TCP协议作为底层传 输协议。说到这里，大家可能觉得，Http与RPC的远程调用非常像，都是按照某种规定好的数据格式进 行网络通信，有请求，有响应。没错，在这点来看，两者非常相似，但是还是有一些细微差别。
HTTP与RPC差别
- RPC并没有规定数据传输格式，这个格式可以任意指定，不同的RPC协议，数据格式不一定相同。
- Http中定义了资源定位的路径，RPC中并不需要
- RPC需要满足像调用本地服务一样调用远程服务，也就是对调用过程在API层面进 行封装。Http协议没有这样的要求，因此请求、响应等细节需要自己去实现。
- 优点：RPC方式更加透明，对用户更方便。Http方式更灵活，没有规定API和语言，跨语言、跨平台
- 缺点：RPC方式需要在API层面进行封装，限制了开发的语言环境
如何选择
- 速度来看，RPC要比http更快，虽然底层都是TCP，但是http协议的信息往往比较臃肿，不过可以采用 gzip压缩。
- 难度来看，RPC实现较为复杂，http相对比较简单
- · 灵活性来看，http更胜一筹，因为它不关心实现细节，跨平台、跨语言。
微服务，更加强调的是独立、自治、灵活。而RPC方式的限制较多，因此微服务框架中，一般都会采用 基于Http的Rest风格服务。
RestFul风格：在相同的URI（http://xxx:xx）下采用不同的请求方式(GET、POST、PUT、DELETE)完成不同操作（查询、插入、修改、删除），不同的表示方式称为RestFul风格
Spring Cloud入门概述Spring的三大模块：SpringBoot（构建），Spring Cloud（协调），Spring Cloud Data Flow（连接）
Spring Cloud介绍
Spring Boot 是 Spring 的一套快速配置脚手架，可以基于Spring Boot 快速开发单个微服务，Spring Cloud是一个基于Spring Boot实现的云应用开发工具；
Spring Boot专注于快速方便开发单个微服务个体，Spring Cloud关注全局的服务治理框架，它将 SpringBoot开发的一个个微服务整合并管理起来，为各个服务之间提供 服务发现、负载均衡、断路器、 路由、配置管理、微代理，消息总线、全局锁、分布式会话等集成服务；
Spring Boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring Boot来实现，可以不基于Spring Boot吗？不可以。 Spring Boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring Boot，属于依 赖的关系。
Spring Cloud主要框架
服务发现——Netflix Eureka
服务调用——Netflix Feign
熔断器——Netflix Hystrix
服务网关——Netflix Zuul
分布式配置——Spring Cloud Config
消息总线 —— Spring Cloud Bus
服务发现组件EurekaEureka介绍
Eureka 是Spring Cloud Netflix 微服务套件中的一部分， 它基于Netflix Eureka 做了二次封装， 主要负 责完成微服务架构中的服务治理功能。我们只需通过简单引入依赖和注解配置就能让Spring Boot 构建 的微服务应用轻松地与Eureka 服务治理体系进行整合。
Eureka包含两个组件：Eureka Server和Eureka Client。
Eureka Server提供服务注册服务。
Eureka Client是一个java客户端，用来简化与Eureka Server的交互、客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。
Eureka的服务剔除与保护机制服务剔除
注册到eureka的服务可能由于内存溢出或网络故障等原因使得服务不能正常的工作，而服务注册中心并 未收到“服务下线”的请求。服务注册中心在启动时会创建一个定时任务，默认每隔一段时间（默认为60 秒）将当前清单中超时（默认为90秒）没有续约的服务剔除，这个操作被称为失效剔除。
服务保护
关停一个服务，很可能会在Eureka面板看到一条警告
这是触发了Eureka的自我保护机制。当服务未按时进行心跳续约时，Eureka会统计服务实例最近15分钟 心跳续约的比例是否低于了85%。
在生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表 并不妥当，因为服务可能没有宕机。
Eureka在这段时间内不会剔除任何服务实例，直到网络恢复正常。生产环境下这很有效，保证了大多数 服务依然可用，不过也有可能获取到失败的服务实例，因此服务调用者必须做好服 务的失败容错。
