开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> Java知识库 -> 系统集成开发复习 -> 正文阅读

[Java知识库]系统集成开发复习

1、系统集成基础

系统集成基本含义

系统集成( system integration)：通常是指将软件、硬件与通信技术组合起来为用户解决信息处理问题的业务，集成的各个分离部分原本就是一个个独立的系统，集成后的整体的各部分之间能彼此有机地和协调地工作，以发挥整体效益，达到整体优化的目的。

系统集成的主要方案

EAI：(Enterprise Application Integration，企业应用整合)

SOA： (service-oriented architecture，面向服务的体系结构) ESB

微服务软件系统架构: SOA的演进

功能分解：将单体应用从功能上分解为多个独立的模块（微服务）单一职责：一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。

面向服务：将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力。

2、Springboot相关

开箱即用的项目框架（Spring Initializer/start.spring.io）

约定大于配置：零配置，无冗余代码生成和XML 强制配置

Starter：按照功能模块的粒度把该功能所用到的依赖包都包含到项目中，减少依赖配置和版本冲突。提供一系列大型项目常用的非功能性特征，如嵌入式服务器、安全性、度量、运行状况检查、外部化配置等。

Spring Boot 不是Spring 的替代者，而是为使用 Spring 做好各种产品级准备

Springboot项目开发的基本步骤

1.创建maven项目
2.引用依赖
起步依赖
项目依赖
3.启动类
4.配置文件
5.业务代码
dto
controller
6.restful测试
7.部署

Springboot项目的特点与基本结构

SpringBoot所具备的特征有：

Springboot是一个微服务框架，延续了spring框架的核心思想IOC和AOP，简化了应用的开发和部署。Spring Boot是为了简化Spring应用的创建、运行、调试、部署等而出现的，使用它可以做到专注于Spring应用的开发，而无需过多关注XML的配置。提供了一堆依赖打包，并已经按照使用习惯解决了依赖问题—>习惯大于约定。

可以创建独立的Spring应用程序，并且基于其Maven或Gradle插件，可以创建可执行的JARs和WARs；
内嵌Tomcat或Jetty等Servlet容器；
提供自动配置的“starter”项目对象模型（POMS）以简化maven配置；
尽可能自动配置Spring容器；
提供准备好的特性，如指标、健康检查和外部化配置；
绝对没有代码生成，不需要XML配置。

Springboot项目基本结构

─main
│ ├─java
│ │ └─com
│ │ └─demo
│ │ ├─config
│ │ ├─controller
│ │ ├─Dao
│ │ ├─handle
│ │ ├─Domain
│ │ ├─service
│ │ │ └─Impl
│ │ └─Application.java

│ └─resources
│ ├─Applications.yml
│ ├─Application. Props
│ └─templates
└─test
└─java
└─com
└─demo

序号	目录/文件	说明
1	src/main/java	java源码目录
2	src/main/java/Application.java	启动类，包含Main方法（jar包方式），命名是自动生成的，可以修改
3	src/main/resources	资源文件目录
4	src/main/resources/templates	模板文件目录，如Thymeleaf、Freemarker等模板引擎的模板文件
5	src/main/resources/static	静态资源目录，如css、js、图片等
6	src/main/resources/application.properties	项目配置文件
7	src/test/java	测试源码目录，如junit单元测试
8	JRE System Library	当前工程使用的Jre
9	Project and External Dependencies	依赖的一些库，展开可以看到列表，有时候找不到类，可以看看这下面有没有引入对应的库

Springboot与Spring的关系

Spring包含了SpringMVC，而SpringBoot又包含了Spring或者说是在Spring的基础上做得一个扩展。

Spring Boot 对比Spring的一些优点包括：

提供嵌入式容器支持
使用命令java -jar独立运行jar
在外部容器中部署时，可以选择排除依赖关系以避免潜在的jar冲突
部署时灵活指定配置文件的选项
用于集成测试的随机端口生成

Swagger的作用及配置要求

Swagger 是一个规范和完整的框架，用于生成、描述、测试和可视化 RESTful 风格的 Web 服务。

接口的文档在线自动生成功能测试

前后端开发人员联系的纽带

Swagger配置

1.pom.xml中添加依赖

2.新建config包，其中新建SwaggerConfig类，类上注解@Configuration、@EnableSwagger2

@EnableSwagger2
@Configuration
public class SwaggerConfig {


    @Bean
    public Docket createRestApi(){
        Docket docket=new Docket(DocumentationType.SWAGGER_2)
                .apiInfo(new ApiInfoBuilder()
                        //.title("swagger-bootstrap-ui-demo RESTful APIs")
                        .description("# swagger-bootstrap-ui-demo RESTful APIs")
                        .version("1.0")
                        .build())
                //分组名称
                .groupName("1.0.1")
                .select()
                //这里指定Controller扫描包路径
                .apis(RequestHandlerSelectors.basePackage("codema.demo.controller"))
                .paths(PathSelectors.any())
                .build();
        return docket;
    }
}

Swagger注解



    @Api(tags="")						///在controller类上注解，tags :说明该接口模块名称

	@ApiOperation(value="", notes="")	///在controller类中的方法前注解value：接口方法名称notes：接口方法说明

	@ApiParam("")						//在方法参数前注解，说明该参数含义

	//对于Controller方法的命令参数（dto对象作为参数）	
	@ApiModel							//注解在Dto类上，说明Dto的用途
	@ApiModelProperty					//注解在Dto类的字段上，说明该参数的含义

多模块Maven项目结构

随着单体应用功能的增加和细化，复杂度迅速增加

使用Maven的多模块配置，可以帮助项目划分模块，鼓励重用，防止POM变得过于庞大，方便某个模块的构建，而不用每次都构建整个项目，并且使得针对某个模块的特殊控制更为方便

拆分方式

横向拆分

按代码层拆分（web层-业务层-数据层）适合单体项目多模块模块复用并行异步构建

纵向拆分

按子系统拆分（用户子系统-订单子系统-商品子系统-评论子系统-物流子系统）

粒度更大功能插拔子系统可作独立项目微服务做准备

3、容器与Docker

计算虚拟化的发展过程

应用环境——远古时代

请添加图片描述

应用环境——虚拟机时代

请添加图片描述

应用环境——容器时代

请添加图片描述

容器技术的基本概念

? 从开发的角度来说就相当于一套开发完成的系统，通过集装箱（容器）技术可以直接运行在计算机A上面，也可以直接运行在计算机B上面，都可以通过计算机中的浏览器来进行访问，不需要在每一台计算机上面重新搭建这个系统需要的环境（比如数据库环境，redis环境等），只需要做一次开发环境的配置即可。

? 所以容器是一种技术，开发人员打包开发完成的一个应用（系统）以及所需的开发环境，然后通过容器可以运行在不同的计算机上面，也不需要重新配置相关环境，不同的是每一台计算机都需要配置运行容器的容器引擎，目前市场上主流就是Docker容器引擎，不过Docker容器引擎的配置很简单，比配置应用（系统）运行的环境简单，方便太多。每台要运行应用（系统）的计算机上面配置了Docker容器引擎之后，都单独独立可以运行之前打包完成的应用（系统）。

Docker镜像与容器

Docker和容器

Docker 是 PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎, 基于go语言并遵从Apache2.0协议开源, 托管在github上.

####Docker镜像

Docker镜像是一个特殊的文件系统（UnionFS，一层一层的系统文件），提供容器运行时所需的程序、库、资源、配置等文件，另外还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。

镜像是一个静态的概念，不包含任何动态数据，其内容在构建之后也不会被改变。

Docker容器

通过Docker引擎运行Docker镜像创建该镜像的容器

容器是镜像的实例，对应系统中的一个实际运行的进程

相对于镜像来说容器是动态的，容器在启动的时候创建了一层可写层次作为最上层

Docker常用命令

请添加图片描述

Docker环境信息   info、version
镜像仓库命令      login、logout、pull、push、search
镜像管理          build、images、import、load、rmi、save、tag、commit
容器生命周期管理  create、exec、kill、pause、restart、rm、run、start、stop、unpause
容器运维操作      attach、export、inspect、port、ps、rename、stats、top、wait、cp、diff、update
容器资源管理      volume、network
系统信息日志      events、history、logs
1.events打印容器的实时系统事件
2.history 打印出指定镜像的历史版本信息
3.logs打印容器中进程的运行日志

容器文件copy
容器->主机：docker cp 容器名:/path/to/file  /path/to/file
主机->容器：docker cp /path/to/file 容器名:/path/to/file

运行容器
docker run –d –name nginx –p 8080:80 nginx
docker run –it –name alpine alpine

用Docker打包Springboot项目

创建Springboot项目并完成功能

Maven构建打jar包

mvn clean package -Dmaven.test.skip=true

编写Dockerfile制作镜像，上传镜像仓库

#Dockerfile内容
FROM jdk:8
RUN mkdir -p /opt/app
ADD ./client.jar /opt/app
ENV JAVA_HOME /opt/jdk
ENV CLASSPATH $JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
ENV PATH $JAVA_HOME/bin:$PATH
EXPOSE 8081
ENTRYPOINT ["java","-jar","/opt/app/client.jar"]

#构建镜像命令
Docker build -t 镜像名称 .

容器部署

#构建容器网络
docker network create testnet
docker run -p 8088:8080 -d --name 容器名  --net testnet  镜像名

项目测试

4、微服务

微服务架构

微服务架构（Microservice Architect）是一种架构模式。它提倡将单块架构的应用划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通（RestTemplate、feign）。每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具进行搭建。

单体应用与微服务应用的比较

单体应用是将所有功能模块放在一个单一进程中，并且通过在不同的服务器上面复制这个单体进行扩展。
微服务架构是将每一个功能模块分别放进到一个独立的服务中，并且通过跨服务器分发这些服务进行扩展，只有需要时才复制。
一个应用程序应该是一组小型服务，通过Http的方式进行互通。

微服务的优点：

单体应用中，如果需要改动功能，那么则需要重新部署整个单体应用。
微服务则只需要重新部署修改的功能模块那个微服务。每一个功能模块都是可独立替换和独立维护的软件单元，完全体现了高可复用性，高可维护性，高可扩展性。

微服务技术框架

Dubbo（RPC）

Provider：暴露服务的提供方，可以通过 jar 或者容器的方式启动服务
Consumer：调用远程服务的服务消费方
Registry：服务注册中心和发现中心
Monitor：统计服务和调用次数，调用时间监控中心。（Dubbo 的控制台页面中可以显示，目前只有一个简单版本。）
Container：服务运行的容器。

Spring Cloud（REST）

Spring Cloud完全基于Spring Boot，是一个非常新的项目，2016年推出1.0的release版本，目前Github上更新速度很快. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，微代理，控制总线，一次性token，全局琐，leader选举，分布式session，集群状态）中快速构建的工具，使用Spring Cloud的开发者可以快速的启动服务或构建应用．它们将在任何分布式环境中工作，包括开发人员自己的笔记本电脑，裸物理机的数据中心，和像Cloud Foundry云管理平台。

Springcloud微服务架构（REST）

Service Provider：暴露服务的提供方。
Service Consumer：调用远程服务的服务消费方
EureKa Server：服务注册中心和服务发现中心

Spring Cloud 子项目分别覆盖了微服务架构下的众多部件，服务治理只是其中的一个方面。

Dubbo 只是实现了服务治理，不过提供了各种 Filter，对于上述中“无”的要素，可以通过扩展 Filter 来完善

从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合 Spring Cloud 的子项目就可以顺利的完成各种组件的融合，而 Dubbo 却需要通过实现各种 Filter 来做定制，开发成本以及技术难度略高。

微服务应用的基本结构与核心组件

架构分解说明

网关集群：数据的聚合、实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制等
业务集群：一般情况下移动端访问和浏览器访问的网关需要隔离，防止业务耦合
Local Cache：由于客户端访问业务可能需要调用多个服务聚合，所以本地缓存有效的降低了服务调用的频次，同时也提示了访问速度。本地缓存一般使用自动过期方式，业务场景中允许有一定的数据延时
服务层：原子服务层，实现基础的增删改查功能，如果需要依赖其他服务需要在 Service 层主动调用
Remote Cache：访问 DB 前置一层分布式缓存，减少 DB 交互次数，提升系统的TPS
DAL：数据访问层，如果单表数据量过大则需要通过 DAL 层做数据的分库分表处理
MQ：消息队列用来解耦服务之间的依赖，异步调用可以通过 MQ 的方式来执行
数据库主从：读写分离，服务化过程中必经的阶段，用来提升系统的 TPS。

五大组件

1.Nacos、Eureka：注册中心

2.Gateway、Zuul：服务网关

3.Ribbon：负载均衡

4.Feign：服务调用(微服务间通信)

5.Hystix：熔断器

5、Dubbo&SpringCloud

RPC

RPC（Remote Procedure Call Protocol）远程过程调用协议。一个通俗的描述是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。比较正式的描述是：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。那么我们至少从这样的描述中挖掘出几个要点：

RPC是协议：既然是协议就只是一套规范，那么就需要有人遵循这套规范来进行实现。目前典型的RPC实现包括：Dubbo、Thrift、GRPC、Hetty等。这里要说明一下，目前技术的发展趋势来看，实现了RPC协议的应用工具往往都会附加其他重要功能，例如Dubbo还包括了服务治等功能。
网络协议和网络IO模型对其透明：既然RPC的客户端认为自己是在调用本地对象。那么传输层使用的是TCP/UDP还是HTTP协议，又或者是一些其他的网络协议它就不需要关心了。既然网络协议对其透明，那么调用过程中，使用的是哪一种网络IO模型调用者也不需要关心
信息格式对其透明：我们知道在本地应用程序中，对于某个对象的调用需要传递一些参数，并且会返回一个调用结果。至于被调用的对象内部是如何使用这些参数，并计算出处理结果的，调用方是不需要关心的。那么对于远程调用来说，这些参数会以某种信息格式传递给网络上的另外一台计算机，这个信息格式是怎样构成的，调用方是不需要关心的
应该有跨语言能力：为什么这样说呢？因为调用方实际上也不清楚远程服务器的应用程序是使用什么语言运行的。那么对于调用方来说，无论服务器方使用的是什么语言，本次调用都应该成功，并且返回值也应该按照调用方程序语言所能理解的形式进行描述。

Dubbo架构的理解

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
远程过程调用：从一个系统（客户主机）中某个程序调用另一个系统（服务器主机）上某个函数的一种方法。RPC的目的是让你在本地调用远程的方法，而对你来说这个调用是透明的，你并不知道这个调用的方法是部署哪里
说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）
其核心部分包含:

远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

##Zookeeper的作用

ZooKeeper是一个开源的分布式协调服务。ZooKeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

ZooKeeper是一个典型的分布式数据一致性的解决方案。分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能

Zookeeper 它提供了配置管理、分布式锁、集群服务等功能。在大数据领域中kafka、Hbase都是使用Zookeeper作为分布式协调服务，来管理集群状态的。知名的Rpc框架Dubbo也是用Zookeeper作为配置管理组件的。

1、集群管理
在分布式集群中，可能由于网络原因、机器故障等情况，需要动态的增删节点，那么集群中节点变更，节点感知就需要一个类似于中心化的服务将变更的节点通知到集群里的各个角色。这时候zookeeper就可以排上用场了，在kafka中，zookeeper用来管理kafka集群的信息，以及consume相关的信息。

2、分布式锁
分布式锁的场景主要也是用在分布式服务中，多节点中想要锁住共享资源，zookeeper是其中的一个选择，使用zookeeper实现分布式锁主要用了它的临时序列节点的机制

3、配置管理
在分布式的应用中，具有非常多配置，怎样做到多节点统一配置，统一更新那就需要一个中心化的协调服务，将配置的变更通知到集群中的所有节点，zookeeper可以做到这一点，说到配置管理，还有一个很强大的开源组件Apollo，在配置管理方面，它更加强大。另外知名的rpc框架dubbo将调用方和服务方相关配置存储到zookeeper中，用于实现服务治理

##Dubbo应用中的关键注解及作用

//	服务提供者
@EnableDubbo			//在启动类上增加注解，用于开启dubbo
@Service(version="${服务版本}",application = "服务提供者id")	//	在服务提供者的Impl服务方法上增加注解

//	服务消费者
@EnableDubbo			//在启动类上增加注解，用于开启dubbo
@Reference(				//服务消费者引用服务的配置标签
	version = "",		// version:dubbo服务的版本号，与服务提供者的版本?致
 	id = ""				//服务引?bean的id，即当前dubbo:reference标签代表的服务的bean的id
)

##Dubbo微服务的开发部署与测试

创建一个项目

consumer 表示一个消费者。
provider 标识一个服务提供者。
provider-api 表示对外提供服务的api.

我们现实的开发中，往往是一个服务既充当服务提供者角色，又充当服务消费者的角色。所以，每个服务都会有一个两个模块，1.provider，服务的实现逻辑模块， 2.provider-api:服务对外暴露的api模块。

引入依赖

创建服务提供者

定义服务间的交互协议(契约/规范)

其实就是定义服务间的RPC接口。

public interface IProviderService {
    /**
     * say hello
     *
     * @return "hello dubbo"
     */
    String sayHello();
}

实现服务提供者的业务逻辑

@Service(verison="服务版本")
public class ProviderServiceImpl implements IProviderService {
    @Override
    public String sayHello() {
        return "hello, dubbo!";
    }
}

对外提供服务

创建服务消费者

在服务消费者的测试中注入提供者服务

消费逻辑

@RestController
public class ConsumerApplication {

	@Reference(version="服务版本")
    IProviderService iproviderService;

	@GetMapping("/hello)
    public String hello(){
        return iproviderService.sayHello();
    }
        
    
}

##Springboot与Springcloud的关系

没有必然的关系
最快的微服务开发方法是springboot
Spring Cloud 通过 Spring Boot 风格的封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、容易部署的分布式系统开发工具包。

##SpringCloud核心组件与功能

Eureka：云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。
Ribbon：提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。
Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
Feign：REST客户端，目的是为了简化WebService客户端的开发
Zuul：为微服务集群提供代理、过滤、路由等功能
Config：分布式配置中心组件，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储（内存）、也支持放在远程Git、 svn。

##SpringCloud应用中关键注解与作用

@EnableDiscoveryClient	（@EnableEurekaClient）	//使得本项目能被Eureka注册中心发现
@EnableFeignCleint						//	开启本项目的微服务之间通信
 
 
 @FeignClient("服务提供者服务名")			//	使用该注解就能使服务提供者提供该类下的方法实现