微服务架构演变过程

传统单体架构 =》 分布式架构 =》 soa面向服务架构 =》 微服务架构

传统单体架构

传统单体架构就是单点应用，也就是在早期开发学习的ssm或ssh整合项目采用分层架构模式、数据库访问层、业务逻辑层、控制层，从前端到后端所有代码都是一个人写的

cn.itycu.controler ---springmvc 视图层 jsp/ftl
cn.itycu.service ---业务逻辑层
cn.itycu.dao ---数据库访问层
将所有的代码都放入到同一个项目中，部署在同一个tomcat中

• 该架构模式存在的优缺点
  • 优点：开发简单、运维简单
  • 缺点：该架构模式没有对业务逻辑进行拆分，这样子耦合度非常高，只适合小团队或者个人形式开发，不适合团队模式协同工作开发，维护性很难，如果系统中某个模块出现问题，会导致整个系统无法使用。
  • 应用场景：政府项目、管理系统、crm、oa，适合于小团队或个人进行开发

分布式架构

分布式架构模式基于传统的架构模式演变过来，将我们传统的单点系统实现根据业务拆分。会拆分为会员系统、订单系统、支付系统、秒杀系统等。从而降低整个项目的耦合度，这种架构模式开始慢慢适合于互联网公司开发。

会员系统 memner.itycu.cn
支付系统 pay.itycu.cn
项目命名为系统意味：包含视图层和服务层

soa面向服务架构

sso单点登录系统，抽离出通用服务
soa面向服务架构基于分布式架构模式演变过来，俗称服务化，也就是面向于服务与接口开发（服务开发），将共同存在的业务逻辑抽取成一个公共服务，提供给其他接口实现调用，服务与服务之间采用rpc远程调用技术。

• 服务：只是有接口、没有视图层

cn.itycu.service
cn.itycu.dao

• 能够解决我们的代码冗余性问题

• soa架构模式特点

  • soa架构模式传输协议采用soap协议（HTTP/https+xml）实现传输，在高并发情况下实现通讯协议存在大量的冗余性传输，而且非常占用带宽。所以后来微服务架构中使用json替代了xml。
  • soa架构模式实现方案webservice或者esb企业服务总线，底层采用soap传输协议。
    • 传统政府、银行项目还是保留的在使用webservice
    • webservice架构模式
    • wsdl组件表示接口信息、方法、调用地址、参数

• soa架构模式存在缺点

  • 采用soap协议实现通讯，xml传输非常重，效率比较低。
  • 服务化管理和治理设施不够完善
  • 依赖于中心服务发现机制
  • 不适合前后端分离架构模式
    • 前后端分离就是对我们控制层和业务逻辑实现区分，前端控制可以采用vue调用我们后端接口（http+json）

微服务架构

微服务架构模式基于soa架构模式演变过来的，比soa架构迷失对服务拆分力度会更加精细，采用前后端分离模式让专业的人做专业的事（专注），目的可以实现高效率开发。微服务架构中，每个服务之间都是互补影响，每个服务必须要独立部署、运维、互不影响，微服务架构模式非常轻巧，轻量级、适合于互联网公司开发模式。
服务与服务之间通讯的协议采用restful形式，数据交换格式采用http+json格式实现传输
整个过程中，采用二进制，所以http协议可以实现跨语言的平台，并且和其他语言实现通讯，所以为什么开放都是采用http+json格式传输

• SOA架构与微服务架构有哪些区别

  • 通讯协议
    • 微服务架构基于soa架构模式演变过来，继承了soa架构的优点，在微服务架构中去除soa架构中soap协议和esp企业服务总线。改为http+json形式传输我们的数据。
      • esb企业服务总线解决多系统间跨语言无法实现通讯的问题，对我们的数据实现转换，可以提供可靠的消息传输。一般情况我们采用http+json传输数据，不需要esb对数据进行转换。
  • 服务拆分力度
    • 微服务架构模式比soa架构模式拆分力度更加精细，提倡让专业的人做专业的事，目的是实现高效的开发，每个服务与服务之间互不影响，每个服务都是单独独立数据库、redis连接、MQ等。并且都是实现独立部署，整个微服务架构更加轻量级。
    • 在soa架构中，有可能纯在多个服务共享同一个数据库，但是微服务架构必须强调每个都是独立数据库部署，互补影响。
  • 迭代
    • 微服务架构模式比soa架构模式，更加适合于互联网公司敏捷、高效、快速迭代版本开发，因为力度非常精细。

• 微服务架构中可能会存在哪些问题

  • 分布式事务解决方案（rabbitmq、rocketmq事务消息、lcn（淘汰）、setata）最终一级概念
  • 分布式任务调度平台（xxl-job、alibabacloud scheduler、elastic-job）
  • 分布式服务注册与发现（eureka、consul、zookeeper、nacos）
  • 分布式日志采集系统elk+kafka
  • 分布式服务最综与调用链系统zipkin
  • 分布式服务配置中心（spring cloud config/携程阿波罗/nacos/disconfig）

微服务架构中有个非常重要的概念：独立部署、可配置、动态化。

为什么要使用到spring cloud

• spring cloud 并不是一个rpc远程调用框架，而是一个微服务全家桶的解决方案的框架。理念就是一条龙服务解决我们在微服务架构中遇到的问题。

  • 服务治理：eureka
  • 分布式配置：config
  • 客户端调用工具：rest/feign客户 rpc远程调用

• 说明：阿里巴巴、腾讯、百度

• 注意：大家如果去一些比较大型的互联网公司中，整个公司内部实现rpc通讯的框架、服务帮助治理都是内部自己研发。

• rpc远程调用框架：HTTPclent、dubbo、feign、grpc、基于netty手写rpc

spring cloud一代和二代的区别

• spring cloud第一代实际上采用Netflix开源的组件整合微服务解决方案。
• spring cloud第二代实际上就是自己研发和国内的优秀的服务解决微服务框架进行组合。比如spring cloudali baba
  • spring cloud Alibaba实际上是为了推广阿里云的产品对我们目前的spring cloud2.x版本实现扩展功能。

nacos实现服务注册于发现

spring cloud与spring cloud Alibaba的区别

• spring cloud Alibaba实际上是为了推广阿里云的产品对我们目前的spring cloud2.x版本和spring cloud1.x版本实现组件扩展功能，能够完美整合到spring cloud开发的组件。
  • nacos分布式注册中心、分布式配置中心spring cloudEureka+config组合。
  • 如果使用spring cloud Alibaba 建议使用Alibaba整个体系的产品。

微服务服务治理核心概念

• Nacos产生背景
  • nacos分布式注册与发现功能 | 分布式配置中心
  • 产生于rpc远程调用中，服务的url的治理
    • rpc远程调用框架：HTTP client、grpc、dubbo、rest、openfeign等。
    • 传统rpc远程调用中存在哪些问题？
      • 超时、安全、服务与服务之间的url地址管理
      • 在我们的微服务架构通讯中，服务间依赖非常大，如果使用传统方式管理我们的服务，非常麻烦，所以采用url治理技术，可以实现我们整个实现动态服务注册与发现、本地负载均衡、容错等

传统服务注册中心的实现方式

• 把每个服务器的地址信息和端口号人工存放到数据库表中

  Id	service	IP	端口号
  1	itycu.cn	192.168.1.1	8080
  2	itycu.cn	192.168.1.1	8000

  • 基于数据库形式实现服务url治理的缺点
    • 维护成本高
    • 没有实现动态自动化

分布式注册中心实现原理

• 注册中心的作用

  • 管理整个微服务url地址
  • 可以实现动态感知

• 注册中心：duboo依赖zookeeper、eureka、consul、nacos、redis、数据库

• nacos与eureka的区别

• eureka与zookeeper的区别

• 注册中心的原理

  • 服务注册：提供服务接口地址信息存放

  key	IP	端口号
  服务名称	192.168.1.1	8080

  生产者启动时，根据这种存储方式注册到微服务注册中心

  • 生产者：提供我们接口被其他服务调用
  • 消费者：调用接口实现服务

  根据以上存储方式的服务名称获取到IP地址和端口号
  获取到地址后在本地实现rpc远程调用

Naxos基本介绍

• 实现注册中心和分布式配置中心
• 默认账号密码：nacos

使用命令模式实现对nacos的注册

使用discovertyClient从注册中心获取接口地址

使用rest Template实现rpc远程调用

纯手写本地负载均衡轮询算法

实现线下服务动态感知