SpringCloud简介

单体架构

缺点：

1.过度的复杂度

  系统本身过于庞大和复杂，以至于任何一个开发者都很难以理解它的全部。这种极度的复杂度会形成恶性循环，由于代码难以理解，因此开发人员更改更容易出错，每一次更改系统更复杂，更难懂。

2.开发速度缓慢

  因为应用太大，每启动一次都需要很长的时间，因此从编辑到构建、运行再到测试这个周期花费的时间越来越长。

3.代码部署的周期很长，而且容易出问题

  程序更改部署到生产环境的时间变得更长。代码库复杂，以至于一个更改可能引起的影响是未知的。开发团队分为多个小组，当需要发布的时候漫长的合并和测试时间非常长。

4.难以扩展

  不能做到按需扩展，只能是扩展整个系统。

5.交付可靠的单体应用是一项挑战

  单体程序缺乏可靠性，这个问题导致了频繁的系统故障和宕机。  应用程序缺乏故障隔离，因为所有模块都运行在同一个进程当中

6.需要长期以来某一个可能已经过时的技术栈

  团队长期使用一套相同的技术，单体架构使得采用新的框架和编程语言变的及其困难。

微服务架构

什么是微服务架构：

简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这祥轻里的机制来相互通信。

这些服务围续业务功能进行构建﹐并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写﹐并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。

微服务优点

1. 独立部署。不依赖其他服务，耦合性低，不用管其他服务的部署对自己的影响。
2. 易于开发和维护：关注特定业务，所以业务清晰，代码量少，模块变的易开发、易理解、易维护。
3. 启动块：功能少，代码少，所以启动快，有需要停机维护的服务，不会长时间暂停服务。
4. 局部修改容易：只需要部署 相应的服务即可，适合敏捷开发。
5. 技术栈不受限：java，node.js等
6. 按需伸缩：某个服务受限，可以按需增加内存，cpu等。
7. 职责专一。专门团队负责专门业务，有利于团队分工。
8. 代码复用。不需要重复写。底层实现通过接口方式提供。
9. 便于团队协作：每个团队只需要提供API就行，定义好API后，可以并行开发。

微服务缺点

1. 分布式固有的复杂性：容错（某个服务宕机），网络延时，调用关系、分布式事务等，都会带来复杂。
2. 分布式事务的挑战：每个服务有自己的数据库，有点在于不同服务可以选择适合自身业务的数据库。订单用MySQL，评论用Mongodb等。目前最理想解决方案是：柔性事务的最终一致性。
3. 刚性事务：遵循ACID原则，强一致性。柔性事务：遵循BASE理论，最终一致性；与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。​BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。
4. 接口调整成本高：改一个接口，调用方都要改。
5. 测试难度提升：一个接口改变，所有调用方都得测。自动化测试就变的重要了。API文档的管理也尤为重要。推荐：yapi。
6. 运维要求高：需要维护 几十 上百个服务。监控变的复杂。并且还要关注多个集群，不像原来单体，一个应用正常运行即可。
7. 重复工作：比如java的工具类可以在共享common.jar中，但在多语言下行不通，C++无法直接用java的jar包。

微服务架构的挑战：

1.运维要求较高

更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行；而在微服务中，需要保证几十甚至几百个服务的正常运行与协作，这给项目的运维带来了很大的挑战。

微服务架构的挑战1.运维要求较高 微服务架构的挑战

2.分布式固有的复杂性

使用微服务构建的是分布式系统。对于一个分布式系统，系统容错﹑网络延迟、分布式事务等都给我们带来了很大的挑战。

3．接口调整成本高

微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。

4．重复劳动

很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。

微服务设计原则

单一职责原则：关注整个系统功能中单独，有界限的一部分。

服务自治原则：可以独立开发，测试，构建，部署，运行，与其他服务解耦。

轻量级通信原则：轻，跨平台，跨语言。REST,AMQP 等。

粒度把控：与自己实际相结合。 不要追求完美，随业务进化而调整。《淘宝技术这10年》。

SpringCloud的替代方案：

SpringCloud -> Alibaba

组件

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架。

Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。

Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

第一阶段课程Spring Cloud技术点

Eureka：服务注册与发现，用于服务管理。

Feign： web调用客户端，能够简化HTTP接口的调用。

Ribbon：基于客户端的负载均衡。

Hystrix：熔断降级，防止服务雪崩。

Zuul：网关路由，提供路由转发、请求过滤、限流降级等功能。

Config：配置中心，分布式配置管理。

Sleuth：服务链路追踪

Admin：健康管理

技术选型

1. Spring Cloud和dubbo组件比较

dubbo：zookeeper+dubbo+springmvc/springboot

通信方式：rpc

注册中心：zookeeper，nacos

配置中心：diamond（淘宝开发）

spring cloud：spring+Netflix

通信方式：http restful

注册中心：eureka，consul，nacos

配置中心：config

断路器：hystrix

网关：zuul，gateway

分布式追踪系统：sleuth+zipkin

1. 差别

	dubbo	spring cloud
背景	国内影响大	国外影响大	平手
社区活跃度	低(现在又好了)	高	cloud胜出
架构完整度	不完善（dubbo有些不提供，需要用第三方，它只关注服务治理）	比较完善，微服务组件应有尽有。	cloud胜出
学习成本	dubbo需要配套学习	无缝spring	cloud胜出
性能	高。（基于Netty）	低。（基于http，每次都要创建）。 此性能的损耗对大部分应用是可以接受的。而HTTP风格的API,是很方便的。用小的性能损耗换来了方便。	dubbo胜出

基础知识补充

QPS和TPS

QPS：Queries Per Second，每秒查询率，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

TPS：Transactions Per Second，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

个人理解如下：

1、Tps即每秒处理事务数，包括了

1）用户请求服务器

2）服务器自己的内部处理

3）服务器返回给用户

这三个过程，每秒能够完成N个这三个过程，Tps也就是N；

2、Qps基本类似于Tps，但是不同的是，对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。

例如：访问一个页面会请求服务器3次，因此一次请求，产生一个“T”，产生3个“Q”