spring-cloud-sofa

第一讲 服务化

 1 以让业务系统只专注于业务，提高业务线拓展速度
 
 2 增加系统的性能，当需要性能进行提升的时候，我们可以从底层服务进行扩容。底层服务的数量越多
  
  系统的整体系统越搞

第二讲 应用服务，核心服务，基础服务

2.1 基础服务 ---- 与业务无关。专注于处理一个领域内的事情

1 基础服务与业务无关，但是业务又依赖于基础服务

2 基础服务向外提供接口，屏蔽了实现细节

3 提供云一样的基础体系服务，快速拓展公司业务线1

2.1.1 center 注册中心服务

提供服务的注册于发现，这个基础服务很简单也很重要

2.1.2 drm 开关服务

这个服务的作用，可以动态控制某一块代码是否运行，主要是用于灰度和环境切换

2.1.3 file 文件服务

   提供文件的上传和下载

2.1.4 mq 消息队列服务

      提供消息队列的功能

2.1.5 message 消息服务

   提供邮件发送，消息发送，短信发送的服务功能

2.2 核心服务

公司自己业务线抽象出来的一些服务
  
2  uic   用户信息中心      
    
     User Information Center  用户中心服务，公司自己的用户生态体系

2.3 应用服务

应用服务这个就比较借地气了，比如  阿里的淘宝，天猫

比如我们公司正在做的  MinService，运营平台

  1  网关服务         每个业务系统的URL转发格式都是不一样的所以这个是第一个应用服务
 
 2  鉴权中心服务     每个业务系统的鉴权也是特殊的

背景

公司没有自研框架的弊端

1 技术形成闭环

   公司发展业务线，新增一条业务线，新接到一个项目，招聘一个高级工程师，然后在这个高级工程师的基础上
   组建了一只团队。这个团队所使用的技术栈不同于公司其他业务线和项目，当这个高级工程师离职以后，基本情况
   就是无法维护不可控。

2 直接使用开源框架导致公司业务线，项目做技术升级改造基本变为不可能的事情。
 
   公司的业务线，项目如果直接使用开源框架，并且业务中存在大量的三方包。当这个开源框架技术落后。
   存在问题。需要替换其他技术的时候，改造成本太大。
   
3 盈利效果低
    
   公司的业务线，和项目 如何才能盈利，快，并且投入人员少。处于业务线和项目位置的时候，开发
   最专注的点应该是业务，一些通用的技术难点如果都放在业务线上和项目上去做，时间成本太大
   而且给业务方很不好的体验。

公司自研框架的好处

盈利角度

1  代码利用得到大量的提升

    相似的功能不存在重复开发的作用，业务上如果碰到相似的应用场景直接复用。
 
2  降低高级工程师的数量
  
    拓展业务线时，基础的架构和技术难点性问题由公司自研框架解决，并且新招入的员工水平能力不用太高
    基础研发部的人员并且为他们进行基础框架培训，让他们快速上手，以解决业务为出发点。

项目质量角度

  1 基础框架负责与第三方框架进行对接工作，当第三方框架存在问题，或需要更换的时候。无须牵动业务部门。
  
  2 代码质量得到提高，公司各个业务线的代码风格一致，技术栈相同，便于维护。

提高公司形象

    1 大型的技术公司都有自研的技术框架，自研技术框架在公司拓展业务线，提升公司在客户心中的形象
    
    上有很大的帮助。

从构建一个 开发平台业务线为例子，讲如何从该框架去拓展一条业务线

1 业务线使用公司的云平台场景

 阶段                                                 产品
                                
研发	                                         1  开发环境基础组件服务能力                      
                                 
                                                 2  脚手架构建开放平台系统基础架构，并连接开发环境基础组件。享受服务能力
                                 
                                                 3  云数据库，云redis ,等
                                                
                                                4   基础平台提供人员进行业务支持（培训，难点问题解决，定制化组件需求）
 
 
                                 
 上线                                            1  提供发布部署服务 

                                                 2   资源管理服务
                                 
 
 
 运维                                          1  日志查看服务                                                
                        
                                               2  分布式链路跟踪服务

                                               3  资源扩容服务


 运营                                         1 大数据平台分析功能

2 项目整包服务的情况

  阶段                                              产品
  
 
 研发                                        1  基础研发部人员参与到现场中，部署开发环境的组件服务

                                            2   架构架构建项目，并连接到现场的开发环境
                                            
                                           3    基础平台提供人员进行业务支持（培训，难点问题解决，定制化组件需求）    



上线                                      1 基础研发部人员在客户的服务器上部署运维需要的基础组件服务
       
                                          2  提供发布部署服务 资源管理服务
                                          

    
运维                                      1  部署运维使用的基础组件服务

                                         2  提供 日志查看服务 分布式链路跟踪服务 资源扩容服务
 

 
运营                                    1  部署运行需要的组件服务
                                         
                                       2    提供大数据平台分析功能

3 收费标准

1 使用公司云平台构建业务收费低

2  项目整包的方式构建业务收费高

脚手架使用详解

 脚手架分为7层
 
 1 api --------   接口 服务层
 
 2 biz  ---------  业务逻辑层
 
 3  core   ------------  核心领域层
 
 4 dal  ---------------   数据持久层 

 5 common   ---------    基础层  
 
 
 6 open-api  ---------------  向外提供服务层

1 api 层详解

  api 层是 接口层，里面定义了业务的接口服务                                           
 
 api层的主要作用如下
   
    1     接收数据    --->  消费   ---->  输出数据
    2    打印日志    --->   用于运维平台收集数据，日志埋点
    3   异常处理    --->   具体的异常均在此处进行统一处理，并且返回给用户可以识别的信息
 
 日志埋点的作用
 
   1 业务上线时，需要统计用户流量主要集中在何种业务上，针对此处进行流量引流
   
   2 统计各个业务流量的使用情况
 
  3  对线上共性问题进行数据分析    

2 业务逻辑层

 1 根据输入的数据，进行业务逻辑处理，业务处理中通用的技术难点进行服务调用方式解决

3 核心领域层

   1  负责的业务抽象，核心业务均在此处进行开发

4 数据持久层

    1 与数据库进行交互，并向上提供服务

5 基础层

  1 定义领域模型（bean）

 2  通用的 工具具类

6 向外提供服务层

 这个是二方包，用于其他系统调用使用             

基础组件详解（构建业务线无关，基础研发部内部文档）

总体模块说明

   spring-cloud-sofa-center        ---------            注册中心       
   
   spring-cloud-sofa-gate          ---------            网关 
   
   spring-cloud-sofa-tracer        ---------            分布式链路追踪 
   
   spring-cloud-sofa-tracer        ---------            分布式框架鉴权
   
   spring-cloud-sofa-drm           ------------         分布式DRM开关
   
   spring-cloud-sofa-file          ------------         分布式文件系统
   
   spring-cloud-sofa-message       ------------          scokcet服务器
   
   spring-cloud-sofa-tari          ------------          缓存服务
   
   spring-cloud-sofa-sidecar      ---------------        第三方接入系统
   
   spring-cloud-sofa-todo        ---------------         代办中心
   
   spring-cloud-sofa-common      ----------------        基础组件基础包

spring-cloud-sofa-center

 1 分布式系统的注册中心，用于存储各个服务的基本信息   技术底层使用的是spring-cloud-eurka。

 2  注册中心部署上分为单节点部署，集群部署俩种方式。这两种方式不同之处，对于框架使用者来说只是编写配置文件

    2.1  单节点部署方式配置文件编写详解
        
        server:
        
          port: 8761 (指定注册中心的端口号，用于其他系统连接时使用)
        
        eureka:
        
          instance:
        
            hostname: localhost (配置当前服务器ip地址)
        
          client:
        
                registerWithEureka: false  (是否将注册中心也进行注册)
        
                fetchRegistry: false       （是否获取注册中心的注册信息）
        
                service-url:                （注册中心的连接地址）
        
                    defaultZone :  http://${eureka.instance.hostname}:${server.port}/eureka/
      2.2 集群配置
      
         此处待补充
         
3  启动注册中心               

     3.1 开发环境

         启动 CenterApplication main 方法即可启动注册中心

     3.2 正式环境

          打成jar包后，java -jar 即可启动

spring-cloud-sofa-gate

 分布式系统的网关，提供对外系统的服务能力，目前底层使用的框架为 spring-cloud-gateway.网关核心能力是提供外部系统调用能力，

 网关状态码已经进行明确的规定，如下图
   
  code（返回码）	msg（返回码描述）	sub_code（明细返回码）	sub_msg（明细返回码描述）	解决方案
    
    10000            服务调用成功
                  
   20000           	服务不可用
   
   20001           	授权权限不足
   
   40001           缺少必选参数
   
   40004           业务处理失败
   
   40006           权限不足	
   
 网关使用的的路由转发策略是
     Path Route  Predicate Factory，配置的原则和nginx 的负载均衡配置相同
     spring:
       cloud:
         gateway:
           routes:
             - id:  spring-cloud-sofa-auth        服务名称，注册在中心的服务
               uri: lb://spring-cloud-sofa-auth   固定格式 lb://服务名称，注册在注册中心的服务
               predicates:  
                 - Path= /api/auth/**             何种url会被转发

spring-cloud-drm

    分布式系统的开关，主要是用于对分布式系统的一些场景可以进行动态的开启，和关闭
    
    使用的时候，在drm的地方注册开关code,开关名称，开关状态 0 为关闭，1为开启
    
    并且提供了一个fegin 的接口，参数为开关code ,返回值为 true 开关开启， false 开关关闭

spring-cloud-sofa-api

    服务化接口的定义位置，A系统想调用C系统的服务，只需要C系统在此处定义自己的接口调用格式。A系统引入此某块
    
    并调用C系统定义的接口 即实现 服务化接口的调用过程