/Bank-of-China

一、Github使用

1.基本命令

cd /F 定位到F盘
ls 查看当前目录下文件
git clone https://github.com/z285098346/Bank-of-China.git 克隆到本地

2.修改并上传文件

本次修改test.txt并上传，操作如下：
git status 查看是否有修改内容需要提交
git add test.txt 指向需要提交的内容文件
git commit -m "test" 提交到本地库
git push origin master 提交到远程仓库
image

3.冲突解决

(1)git冲突的场景

  • 情景一：多个分支代码合并到一个分支时；
  • 情景二：多个分支向同一个远端分支推送代码时；

实际上，push操作即是将本地代码merge到远端库分支上。

关于push和pull其实就分别是用本地分支合并到远程分支和将远程分支合并到本地分支,所以这两个过程中也可能存在冲突。

git的合并中产生冲突的具体情况：
<1>两个分支中修改了同一个文件（不管什么地方）
<2>两个分支中修改了同一个文件的名称 两个分支中分别修改了不同文件中的部分，不会产生冲突，可以直接将两部分合并。

(2)冲突解决方法

  • 情景一：在当前分支上，直接修改冲突代码--->add--->commit。
  • 情景二：在本地当前分支上，修改冲突代码--->add--->commit--->push
    注：借用vim或者IDE或者直接找到冲突文件，修改。

二、几个基本概念

1.单点登录：

单点登录（Single Sign On），简称为 SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

  • 所有应用系统共享一个身份认证系统。
    统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。
  • 所有应用系统能够识别和提取ticket信息
    要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

三种实现方式：

  • 以Cookie作为凭证媒介

        最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。用户登录父应用之后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，授权应用解密cookie并进行校验，校验通过则登录当前用户。
image
        不难发现以上方式把信任存储在客户端的Cookie中，这种方式很容易令人质疑：
        (1)Cookie不安全
        (2)不能跨域实现免登

  • 通过JSONP实现
            对于跨域问题，可以使用JSONP实现。用户在父应用中登录后，跟Session匹配的Cookie会存到客户端中，当用户需要登录子应用的时候，授权应用访问父应用提供的JSONP接口，并在请求中带上父应用域名下的Cookie，父应用接收到请求，验证用户的登录状态，返回加密的信息，子应用通过解析返回来的加密信息来验证用户，如果通过验证则登录用户。
    image
            这种方式虽然能解决跨域问题，但是安全性其实跟把信任存储到Cookie是差不多的。如果一旦加密算法泄露了，攻击者可以在本地建立一个实现了登录接口的假冒父应用，通过绑定Host来把子应用发起的请求指向本地的假冒父应用，并作出回应。因为攻击者完全可以按照加密算法来伪造响应请求，子应用接收到这个响应之后一样可以通过验证，并且登录特定用户。
  • 通过页面重定向的方式
            最后一种介绍的方式，是通过父应用和子应用来回重定向中进行通信，实现信息的安全传递。父应用提供一个GET方式的登录接口，用户通过子应用重定向连接的方式访问这个接口，如果用户还没有登录，则返回一个的登录页面，用户输入账号密码进行登录。如果用户已经登录了，则生成加密的Token，并且重定向到子应用提供的验证Token的接口，通过解密和校验之后，子应用登录当前用户。
    image
            这种方式较前面两种方式，接解决了上面两种方法暴露出来的安全性问题和跨域的问题，但是并没有前面两种方式方便。

2.前后端分离：

  • 前端：html、css，JavaScript，面向的是用户，如果载体是浏览器或移动设备，语言主要是JavaScript。
  • 后端：基于web容器提供应用服务，可以是java、net语言，还可以是nodejs等等。

        在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App有App的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。

  • 前端与后端的耦合度相对较低。
  • 通常将后端开发的每个视图都称为一个接口，或者API，前端通过访问接口来对数据进行增删改查。 image

3.微服务：

一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，将应用程序构造为一组松散耦合的服务。在微服务体系结构中，服务是细粒度的，协议是轻量级的。
微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。

  • 有自己的堆栈，包括数据库和数据模型；
  • 通过REST API，事件流和消息代理的组合相互通信；
  • 和它们是按业务能力组织的，分隔服务的线通常称为有界上下文。

尽管有关微服务的许多讨论都围绕体系结构定义和特征展开，但它们的价值可以通过相当简单的业务和组织收益更普遍地理解：

  • 可以更轻松地更新代码。
  • 团队可以为不同的组件使用不同的堆栈。
  • 组件可以彼此独立地进行缩放，从而减少了因必须缩放整个应用程序而产生的浪费和成本，因为单个功能可能面临过多的负载。

三、BPMN

1.定义

        由BPMI开发了一套标准叫业务流程建模符号(BPMN - Business Process Modeling Notation)。BPMN的主要目标是提供一些被所有业务用户容易理解的符号，从创建流程轮廓的业务分析到这些流程的实现，直到最终用户的管理监控。BPMN也支持提供一个内部的模型可以生成可执行的BPEL4WS。因此BPMN的出现，弥补了从业务流程设计到流程开发的间隙。
        BPMN定义了一个业务流程图（Business Process Diagram），该业务流程图基于一个流程图（flowcharting），该流程图被设计用于创建业务流程操作的图形化模型。而一个业务流程模型（Business Process Model），指一个由图形对象（graphical objects）组成的网状图，图形对象包括活动（activities)和用于定义这些活动执行顺序的流程控制器（flow controls）。

2.包含的元素

  • 流对象（FlowObjects）：包括其中的活动、事件与网关。
  • 连接对象（ConnectingObject）：流对象通过连接对象连接起来表示数据的流转。
  • 数据（Data）：包括一些数据对象、数据输入\输出对象等。
  • 泳道（Swimlanes）：对业务做范围维度的区分，一般通过不同的职能进行区分。

池（Pools ）： 池描述流程中的一个参与者。可以看做是将一系列活动区别于其他池的一个图形容器
道（Lanes ）：道就是在池里面再细分，可以是垂直的也可以是水平的。道也是用于组织和分类活动。

  • 描述对象（Artifacts）：不影响流程运行，为流程图可读性进行补充性描述。
    image

3.camunda实践

  • 流程图 image
  • XML代码 image

四、Docker和容器

1.什么是容器？

容器就是将软件打包成标准化单元，以用于开发、交付和部署。

  • 容器镜像是轻量的、可执行的独立软件包 ，包含软件运行所需的所有内容：代码、运行时环境、系统工具、系统库和设置。
  • 容器化软件适用于基于Linux和Windows的应用，在任何环境中都能够始终如一地运行。
  • 容器赋予了软件独立性，使其免受外在环境差异（例如，开发和预演环境的差异）的影响，从而有助于减少团队间在相同基础设施上运行不同软件时的冲突。

2.什么是Docker?

  • Docker是世界领先的软件容器平台。
  • Docker使用Google公司推出的Go语言进行开发实现，基于Linux内核的cgroup，namespace，以及AUFS类的UnionFS等技术，对进程进行封装隔离，属于操作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。Docker最初实现是基于LXC。
  • Docker能够自动执行重复性任务，例如搭建和配置开发环境，从而解放了开发人员以便他们专注在真正重要的事情上：构建杰出的软件。
  • 用户可以方便地创建和使用容器，把自己的应用放入容器。容器还可以进行版本管理、复制、分享、修改，就像管理普通的代码一样。

3.Docker的基本概念

  • 镜像（Image）——一个特殊的文件系统
            Docker镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。 镜像不包含任何动态数据，其内容在构建之后也不会被改变。
            Docker设计时，就充分利用Union FS的技术，将其设计为分层存储的架构。 镜像实际是由多层文件系统联合组成。
            镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。比如，删除前一层文件的操作，实际不是真的删除前一层的文件，而是仅在当前层标记为该文件已删除。在最终容器运行的时候，虽然不会看到这个文件，但是实际上该文件会一直跟随镜像。因此，在构建镜像的时候，需要额外小心，每一层尽量只包含该层需要添加的东西，任何额外的东西应该在该层构建结束前清理掉。
  • 容器（Container）——镜像运行时的实体
            镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等 。
            容器的实质是进程，但与直接在宿主执行的进程不同，容器进程运行于属于自己的独立的命名空间。前面讲过镜像使用的是分层存储，容器也是如此。
            容器存储层的生存周期和容器一样，容器消亡时，容器存储层也随之消亡。因此，任何保存于容器存储层的信息都会随容器删除而丢失。
            按照Docker最佳实践的要求，容器不应该向其存储层内写入任何数据 ，容器存储层要保持无状态化。所有的文件写入操作，都应该使用数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。数据卷的生存周期独立于容器，容器消亡，数据卷不会消亡。因此， 使用数据卷后，容器可以随意删除、重新run，数据却不会丢失。
  • 仓库（Repository）——集中存放镜像文件的地方
            镜像构建完成后，可以很容易的在当前宿主上运行，但是， 如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry就是这样的服务。
            一个Docker Registry中可以包含多个仓库（Repository）；每个仓库可以包含多个标签（Tag）；每个标签对应一个镜像。所以说：镜像仓库是Docker用来集中存放镜像文件的地方类似于我们之前常用的代码仓库。

4.Docker的特性

  • 文件系统隔离：每个进程容器运行在完全独立的根文件系统里。
  • 资源隔离：可以使用cgroup为每个进程容器分配不同的系统资源，例如CPU和内存。
  • 网络隔离：每个进程容器运行在自己的网络命名空间里，拥有自己的虚拟接口和IP地址。
  • 写时复制：采用写时复制方式创建根文件系统，这让部署变得极其快捷，并且节省内存和硬盘空间。
  • 日志记录：Docker将会收集和记录每个进程容器的标准流（stdout/stderr/stdin），用于实时检索或批量检索。
  • 变更管理：容器文件系统的变更可以提交到新的映像中，并可重复使用以创建更多的容器。无需使用模板或手动配置。
  • 交互式Shell：Docker可以分配一个虚拟终端并关联到任何容器的标准输入上，例如运行一个一次性交互shell。