微服务三期02-1 微服务演进、技术选型和组件介绍、Spring Cloud介绍

传统服务到微服务的演进：单体应用-->SOA-->微服务
        单体应用：
                概念：所有功能全部打包在一起。整个应用为一个程序包
                优点：容易开发、测试、部署，适合项目初期试错
                缺点：随着项目越来越复杂，团队不断扩大。坏处就越明显
                        复杂性高：代码多，十万行，百万行级别。加一个小功能，会带来其他功能的隐患，因为代码都在同一个项目里
                        技术债务：人员流动，不坏不修，因为不敢修
                        持续部署困难：由于是全量应用，改一个小功能，全部部署，会导致无关的功能暂停使用。编译部署上线耗时长，不敢随便部署，导致部署频率低，进而又导致两次部署之间 功能修改多，越不敢部署，恶性循环
                        可靠性差：某个小问题，比如小功能出现BUG，会导致整个应用崩溃
                        扩展受限：只能整体扩展，无法按照需要进行扩展，  不能根据计算密集型（派单系统）和IO密集型（文件服务） 进行合适的区分
                        阻碍创新：单体应用是以一种技术解决所有问题，不容易引入新技术。但在高速的互联网发展过程中，适应的潮流是：用合适的语言做合适的事情。比如在单体应用中，一个项目用spring MVC，想换成spring Boot，切换成本很高，因为有可能10万，百万行代码都要改，而微服务可以轻松切换，因为每个服务功能简单，代码少
                                
        SOA架构：
                对单体应用的改进：引入SOA（Service-Oriented Architecture）面向服务架构，拆分系统，用服务的流程化来实现业务的灵活性。服务间需要
                某些方法进行连接，面向接口等，它是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独
                立的形式存在于操作系统进程中。各个服务之间通过网络调用。但是还是需要用些方法来进行服务组合，有可能还是个单体应用。
                
                （所以要引入微服务，是SOA思想的一种具体实践。微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想）

        微服务：
                概念：微服务是一种设计风格，它提倡将单一应用程序划分成多个微小的服务，服务之间通过互相协调、互相配合，为用户提供最终价值；
                系统中的每个服务互不影响、可被独立部署，每个服务仅关注于完成一件任务。（http://www.martinfowler.com/articles/microservices.html）
                特性：
                        独立运行在自己的进程中
                        一系列独立服务共同构建起整个系统
                        一个服务只关注自己的独立业务
                        轻量级的通信机制和RESTFul API-->跨语言调用
                        devops全自动部署机制
                 设计原则：
                        单一职责原则：关注整个系统功能中单独，有界限的一部分。
                        服务自治原则：可以独立开发，测试，构建，部署，运行，与其他服务解耦。
                        轻量级通信原则：轻，跨平台，跨语言。REST,AMQP 等。
                        粒度把控：与自己实际相结合。 不要追求完美，随业务进化而调整。《淘宝技术这10年》。
                优点：
                        组件服务化：
                                业务：帮助企业更快的响应变化，增加或减少业务时系统可快速响应
                                管理：按业务需求划分开发团队，负责内容耦合度低易扩展业务
                                开发：敏捷开发、高效率，只需关注自己的任务，不需要了解整个业务或者其他业务
                        去中心化：解决SOA架构使用的ESB（企业服务总线）带来的各种问题：比如依赖的项目越来越多关系越来越复杂、可用性问题
                        基础设施自动化（DevOps环境）：DevOps一词来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，
                                通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠
                                CI：持续集成、从构建、研发环境、测试环境和类生产环境等，解决开发和运维之间的沟通协作
                                CD：持续交付、完成测试的代码持续交付给运维做接下来工作
                                CD：持续部署（容器（Docker）、容器编排（K8s））、运维收到交付来的程序包后使用工具（K8s，Docker）自动化完成部署操作、完成监控，资源分配和升降机过程
                缺点：
                        分布式固有的复杂性：容错（某个服务宕机），网络延时，调用关系、分布式事务等，都会带来复杂
                        分布式事务的挑战：每个服务有自己的数据库，有点在于不同服务可以选择适合自身业务的数据库。订单用MySQL，评论用Mongodb等。
                                目前最理想解决方案是：柔性事务的最终一致性
                        接口调整成本高：改一个接口，调用方都要改
                        测试难度提升：一个接口改变，所有调用方都得测。自动化测试就变的重要了。API文档的管理也尤为重要（推荐yapi）
                        运维要求高：需要维护几十上百个服务。监控变的复杂。并且还要关注多个集群，不像原来单体，一个应用正常运行即可
                        重复工作：比如java的工具类可以在共享common.jar中，但在多语言下行不通，C++无法直接用java的jar包
               

微服务的技术选型和组件介绍
        
        组件：不局限与具体的微服务实现技术
                服务注册与发现：服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址
                负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方来说是透明的
                服务网关：服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能
                        灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品
                        特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以
                        保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
                配置中心：将本地化的配置信息(Properties、XML、YAML等形式)注册到配置中心，实现程序包在开发、测试、生产环境中的无差别性，方便程
                        序包的迁移，也是无状态特性
                集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件(特别是管理端组件)集成到统一的界面框
                        架下，让用户能够在统一的界面中使用系统。Spring Cloud就是一个集成框架
                调用链监控：记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点
                支撑平台：系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分
                        的工作自动化。现在，Docker等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿发布、健康检查、性能监控等等。如果
                        没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效
                                1. 蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本
                                2. 灰度是选择部分部署新版本，将部分流量引入到新版本，新老版本同时提供服务。等待灰度的版本OK，可全量覆盖老版本
                                灰度是不同版本共存，蓝绿是新旧版本切换，2种模式的出发点不一样

Spring Cloud介绍：
        概念：Spring Cloud是实现微服务架构理念的一系列框架的集合，建立在Spring Boot基础上构建，用于简化分布式系统构建的工具集。是拥有众多子项目的项目集合。利用Spring Boot的开发便利性，巧妙地简化了分布式系统基础设施（服务注册与发现、熔断机制、网关路由、配置中心、消息总
                线、负载均衡、链路追踪等）的开发
                
        发展：Spring Cloud 自 2016 年 1 月发布第一个 Angel.SR5 版本，到目前 2020年3月发布 Hoxton.SR3 版本，已经历经了 4 年时间。这 4 年时间
                里，Spring Cloud 一共发布了46个版本，支持的组件数从 5 个增加到 21 个。Spring Cloud 在 2019 年 12 月对外宣布后续 RoadMap：
                        下一个版本 Ilford 版本是一个大版本。这个版本基于 Spring Framework 5.3 & Spring Boot 2.4，会在 2020 Q4 左右发布
                        Ilford 版本会删除处于维护模式的项目。目前处于维护模式的 Netflix 大部分项目都会被删除（spring-cloud-netflix Github 项目已经删除了这些维护模式的项目）
                        简化 Spring Cloud 发布列车。后续 IaasS 厂商对应的 Spring Cloud 项目会移出 Spring Cloud 组织，各自单独维护（spring-cloud-azure 一直都是单独维护，spring-cloud-alibaba 孵化在 Spring Cloud 组织，毕业后单独维护）
                        API 重构，会带来重大的改变（Spring Cloud Hoxton 版本新增了 Spring Cloud Circuit Breaker 用于统一熔断操作的编程模型和 Spring Cloud  LoadBalanacer 用于处理客户端负载均衡并代替 Netflix Ribbon）
                             
        版本演进：
                1. 版本过程：版本名.版本号
                2. 版本名：伦敦地铁字母顺序
                3. 版本号：
                        M（milestone）：里程碑
                        SR（Service Releases）：稳定版
                        RC(Release Candidate)：稳定版的候选版，也就是稳定版的最后一个版本
                        （查询每个cloud版本下面的子模块的版本，https://spring.io/projects/spring-cloud网页最下面，目前最新版本是：Greenwich.SR2）
        
        SpringCloud替代实现：
                
                
        有三家公司对Spring Cloud提供实现方案：Apache、NetFlix、Alibaba
                
        SpringCloud NetFlix：
                Eureka：服务注册与发现，用于服务管理
                Feign： web调用客户端，能够简化HTTP接口的调用
                Ribbon：基于客户端的负载均衡
                Hystrix：熔断降级，防止服务雪崩
                Zuul：网关路由，提供路由转发、请求过滤、限流降级等功能
                Config：配置中心，分布式配置管理
                Sleuth：服务链路追踪Admin：健康管理
                
        SpringCloud Alibaba（组件）：https://github.com/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：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道