.netcore下的微服务、容器、运维、自动化发布

时间 2019-11-12

原文原文链接

微服务

1.1 基本概念html

1.1.1 什么是微服务？python

微服务架构是SOA思想某一种具体实现。是一种将单应用程序做为一套小型服务开发的方法，每种应用程序都在其本身的进程中运行，并采用轻量级的通信机制（TCP）进行通讯。这些服务是围绕业务功能构建的，能够经过全自动部署机制进行独立部署。这些服务的集中化管理已是最少的，它们能够用不一样的编程语言编写，并使用不一样的数据存储技术。linux

1.1.2 为何要用微服务？git

1.1.2.1 微服务解决了什么问题？github

在微服务的最佳实践中都提到若是一个项目以微服务做为起点，则大几率会陷入项目失败。微服务的本质是解决了团队分工的问题，当项目团队的开发人员没法解决大型单体应用的问题或虽然能够解决问题但成本高昂的时候，微服务每每才是最佳实践。经过从外围不断拆分单体架构的业务，以细粒度的单项服务的形式发布服务，最终将单体架构微服务化。web

1.1.2.2 微服务带来了什么挑战？算法

微服务首先是对组织架构的调整提出的新的挑战，微服务要求每个服务尽量的独立和内聚，这要求这个团队符合2pizza风格，也就是说每个团队都尽量的包含从开发到测试到运维人员组成的独立项目组。而不是传统大型企业中以横向切割的形式让开发、运维、测试各是一个独立部门。spring

微服务的第二个挑战是带来了分布式下开发、测试与运维的复杂性。微服务本质上并非什么银弹，它解决了团队面对单体架构疲于奔命的开发和部署问题，可是也引来了新的问题。在单体开发过程当中，开发人员不会想到方法调用会失败、会重试、要幂等。测试人员不会考虑几十个应用怎么一块儿集成测试，运维人员不会考虑下游应用挂了对我有什么影响。意识到分布式下开发、测试与运维的复杂性，并掌握这些复杂问题的方法才是更主要的。docker

1.2 架构设计shell

1.2.1 服务注册/发现

服务治理解决了分布式应用中服务依赖复杂度的问题，当数十个应用须要统一的管理进行服务发现、负载均衡、服务降级、服务下线时。没有一个统一的管理方式是没法实现的，服务治理的概念也应运而生。服务治理中最重要的部分就是服务的注册和发现，以dubbo为例，服务提供者启动后向注册中心注册本身提供的服务。消费者(有多是其余服务、也有多是网关)启动，向注册中心订阅本身须要的服务。注册中心返回服务提供者的健康检查(心跳)列表，消费者根据软负载算法(轮询/随机/hash一致/最小压力优先)选择一台发起请求。

1.2.2 分布式通信

1.2.2.1 REST API/RPC

通常在微服务架构中，服务和服务之间因为进程隔离甚至物理机隔离，每每会采用一种通用的网络通信模式，以目前主流的设计来讲有两种方案，一种是基于HTTP协议的rest api方式。这种方式下每个生产者以rest api的形式暴露本身的接口到注册中心。消费者从注册中心拉取到生产者列表后经过httpclient的形式发起请求并得到结果。Rpc协议也是基于网络的请求协议，rpc经过TCP的形式(如dotnetty)采用远程过程调用的方式，让本地应用调用远程应用就和调用本地过程同样方便(new remoteprocessserver().get({id=1}))。

1.2.2.2 事件总线

微服务中因为服务和服务之间采用了物理级的数据隔离机制，而在单体架构中很容易实现的事务在微服务中成了复杂的分布式问题，目前的解决办法是引入事件总线(event bus)的机制来实现分布式环境下的事务问题，事件总线采用了观察者模式，经过订阅发布到事件总线来实现消息的最终一致性。订阅者订阅消息，发布者产生消息后发布到事件总线，事件总线异步通知(基于第三方的消息队列，如rabbitmq)订阅者，订阅者处理消息。订阅者能够经过一些机制好比重试和幂等机制保证消费的消息必定可以被消费一次。若是稍微复杂则须要引入TCC这样的机制保证消息消费失败能够及时回滚（.netcore目前国内有开源的CAP能够实现eventbus并内置的tcc，无需开发者实现复杂的应用层tcc）

1.2.3 网关

微服务中，网关是全部服务对外提供的一个统一窗口。网关本质就是一个路由器，经过这个路由器，咱们能够将外界(PC/APP/IOT/CLOUD)的请求进行统一的鉴权、限流、监控后对内调用服务，从而起到了保护内部服务接口安全的目的。

1.2.3.1 服务鉴权

用户调用的某一个接口须要进行权限身份验证时，能够经过网关集成identity进行统一的鉴权管理，而无需每个应用本身去实现鉴权。也能够经过独立的受权服务器来处理，网关将每个须要鉴权的请求经过受权服务器作校验，再由受权服务器受权后通知网关调用具体的服务

1.2.3.2 服务限流

网关能够经过对每一个服务进行限流来保障在高并发中服务由于没法及时处理请求而挂掉，好比当某个服务的请求在单位时间内超过了设定阈值，则网关能够直接返回给调用者一个友好的回调或者经过缓存的形式返回以前的结果。

1.2.3.3 熔断降级

网关能够经过熔断的机制来保障某一个服务的可用性，好比当某个服务变得不可用的时候，好比当调用者屡次请求某个服务都超时，当超时次数超过设定阈值的时候，网关能够对该类型的服务进行熔断，全部对该服务的请求都会收到网关的友好回调或旧缓存。网关会在熔断时启动一个定时做业定时检查该服务的可用性，直到该服务从新能够被访问时才能从新接入网关

1.2.4 配置中心

单体式应用中，通常采用传统的配置文件的形式进行本地化配置，方便统一管理或热更新。可是在分布式环境下若是没有一个分布式的配置中心做为支撑，动辄几百个微服务应用是没办法及时进行统一配置的。因此一个统一的分布式配置中心是有必要存在的。经过统一的配置中心管理全部应用的配置，应用经过初始化拉取的形式作更新。应用内部依旧采用热更新的形式读取配置数据。

1.2.5 下一代微服务架构

1.2.5.1 Service Mesh

这一套解决方案提供了一套基于基础设施的，对语言和应用自己无依赖的服务网格来提供上一代微服务中心化的网关/注册中心/缓存/负载均衡等等功能。好比基于k8s实现的istio。本质上是经过对容器注入sidercar的形式无感知的实现服务治理。而无需关注服务自己是用何种语言编写的何种服务。Service fabric也是提供相似的功能的平台。

1.2.5.2 Serverless

Serverless 是提供微服务的一种简化开发、自动化运维、资源分时复用的解决方案，好比Flink(略)

1.3 具体实践

1.3.1 如何经过.netcore+surging+DDD实现微服务？

surging 是一个分布式微服务框架,提供高性能RPC远程服务调用，服务引擎支持http、TCP、WS协议,采用Zookeeper、Consul做为surging服务的注册中心，集成了哈希，随机，轮询、压力最小优先做为负载均衡的算法，RPC集成采用的是netty框架，采用异步传输。项目地址https://github.com/dotnetcore/surging

在surging的基础上我进行了一些本地化实现，好比受权服务分离。并为应用提供了一套ddd的基础设施以及自动发布以及运维监控部分的集成。项目地址https://gitee.com/gmmy/Microservices

容器（docker）

2.1 基本概念

2.1.1 什么是容器？

容器基于Linux Container技术，它是一种内核轻量级的操做系统层虚拟化技术。最单纯的理解就是经过容器技术，你能够很方便的将你的应用打包到某一个指定的环境(centos/ubuntu/alpine)构建特定的镜像，这个镜像能够经过世界上任意一台安装了docker的服务器进行拉取并成功运行，解决了以往应用在不一样环境中表现不一致的问题。

2.1.2 容器和虚拟机的区别？

容器和虚拟机最大的区别在于容器自己是依赖于linux操做系统的的半独立系统而虚拟机则是拥有独立操做系统的沙箱。容器又在此的基础上提供了进程级的隔离和文件数据隔离，基本作到了虚拟机的体验而资源占用又比虚拟机少了不少。

2.1.3 镜像/容器/自动化构建

2.1.3.1 容器

容器就是docker中的独立最小化单元，是一个运行起来的镜像。内部包含一个操做系统+环境+应用程序。好比(centos+jvm+spring boot)/又或者(Ubuntu+python+flaskwebapp)。虽然容器自己对应用并未有安装限制，但实际开发时必须根据关注点分离的原则一个容器只运行1个应用。

2.1.3.2 镜像

镜像就是容器的原始文件。当咱们经过命令构造一个镜像后，能够经过run很方便的把这个镜像启动成一个或一组容器(集群)。有点相似于编程中的类定义文件和运行时的类实例，一个类定义文件在运行时能够建立1个或多个内存中运行的实例，由应用来管理它的生命周期。咱们也能够经过容器快照的方式将某个容器在某个时间点的快照导出成镜像。该镜像会保留容器快照时的全部状态。

2.1.3.3 自动化构建

容器能够经过docker build和docker compose的方式进行自动化构建。前者主要经过dockerfile的形式将本地的应用配合仓库中的镜像进行一组打包操做造成一个镜像。后者则能够直接经过调用多个dockerfile/命令的方式启动一组镜像（好比一个微服务项目含有多个应用。能够经过此方式一次性所有运行起来）

2.1.4 镜像仓库/市场

镜像仓库/市场就是存放镜像的云平台，docker官方提供了(https://hub.docker.com)做为镜像市场能够免费(2018.11)上传您的本地仓库中的镜像，可是因为国内已知的缘由，仍是推荐使用国内云提供商提供的免费(2018.11)镜像市场(https://www.aliyun.com/product/acr?utm_co

ntent=se_1000088670)或者私有化部署本身的镜像仓库（https://www.cn

blogs.com/Javame/p/7389093.html）。

2.1.5 容器编排

Docker自己提供了基于shell的方式对单个服务器的容器集合进行简单的管理，可是在实际的生产过程当中，咱们依然须要更增强大的集中式管理工具来管理咱们跨数个服务的容器集群，k8s就是基于这样一个容器管理编排平台，能够经过它很方便的管理容器的生命周期，从应用建立、部署、扩容、更新、调度都可以在一个平台上完成，而无需建立复杂的脚本进行运维管理。

2.2 具体实践

2.2.1 如何经过容器进行asp.netcore应用的发布？

2.2.1.1 准备工做

2.2.1.1.1 环境

Linux/windows

Docker/docker for windows

Docker-compose(非必须，需单独安装)

Asp.net core app（咱们假设应用已经发布并打包好了）

2.2.1.2 发布流程

打包镜像通常咱们推荐采用dockerfile的形式来完成。

首先在应用所在目录建立一个没有后缀的名称叫Dockerfile的文件，用vim或者txt打开并编辑它（取决于您采用什么操做系统）

命令以下:

#咱们须要从本地仓库拉取一个基础镜像(dotnetcore runtime)

FROM microsoft/dotnet:2.1-runtime

#设置咱们的工做目录，后面的操做包括文件复制，命令启动如无必要均默认在该目录执行

WORKDIR /app

#将当前dockerfile所在文件夹全部文件复制到镜像对应的workdir目录中

COPY . .

#设置容器的默认启动命令

ENTRYPOINT ["dotnet", "Web.dll"]

这样一个简单的dockerfile就建立好了。接下来你能够经过docker build . –t ‘imagename’ 来构建镜像并经过docker run 的形式来运行它，或采用docker-compose的方式来直接构建并运行它.

Docker-compose 方式

在刚才的目录中能够建立一个docker-compose.yml文件进行容器编排(此处的编排仅仅指打包运行一组容器非k8s)

内容以下

version: '3.4'

services:

#名称，可随意

servicename:

#环境变量，根据应用实际须要指定传入

environment:

- Register_Conn=192.168.0.171:80

#是否默认启动

restart: always

#指定镜像名称，经过build打包后的镜像名称

image: servicename:latest

#指定打包，若没有则会直接根据上一步的镜像名称构建容器

build:

#打包路径

context: .

dockerfile: Dockerfile

#构建的容器名称

container_name: servicename

#对外映射端口，左侧是服务器对外开放的端口，右侧是容器内开放的端口，假设个人asp.netcore指定了80端口映射到服务器提供的8080端口

ports:

- "8080:80"

经过简单的执行 docker-compose up –d –-build 就能够很方便的将应用运行起来了。

自动发布

3.1 基本概念

3.1.1 什么是CI/CD&CD?

CI/CD&CD字面意思就是指持续集成，持续部署，持续交付。指出在软件研发过程当中须要经过自动化构建的方式将产品可以快速的高质量的进行交付和迭代，区别于以往小做坊式的手工方式打包部署，避免了人为缘由形成的软件部署失败以及提高了部署效率。

3.2 具体实践

3.2.1 Gitlab+gitlabCI+gitlabRunner

软件安装

Gitlab: http://www.javashuo.com/article/p-ssstonyj-dr.html

gitlab-runner: http://www.javashuo.com/article/p-akriurix-dn.html

ci&cd具体落地依赖于版本管控软件以及自动化构建工具以及容器技术，我这里采用的例子是gitlab自带的gitlabci工具。

其发布流程以下：push代码到gitlab->gitlab根据根目录的.gitlab-ci.yml文件发布ci命令，若当前项目部署了对应的gitlabci，则ci工具会启动对应的gitlabrunner这个进程开始执行对应的命令并推送构建好的镜像到远程服务器，大体的流程以下图：

3.2.2 单元测试(xtest)与质量管控(SonarQube)

单元测试对于软件开发来讲是必要的，因此须要接入单元测试。.netcore推荐xunit做为单元测试工具。

https://www.cnblogs.com/ccccc05/archive/2017/08/01/7266914.html

代码质量管控也是一个必要的过程，经过对上传代码的分析，能够找出一些人为忽略掉的质量问题，方便后续版本的改进。

http://www.cnblogs.com/qiumingcheng/p/7253917.html

运维监控

4.1 基本概念

4.1.1 APM

Apm致力于监控管理应用软件性能和可用性，单体应用时代APM的需求并不是特别强烈。可是基于微服务的分布式架构下，多个服务的性能稳定可用必须统一检测和管控起来。

4.1.2 日志与异常

以往的单体应用每每采用日志文件或者数据库记录的方式来管理日志和异常(好比知名的log4j)，和其余单体应用转分布式同样的问题就是每个应用的异常数据和日志都须要统一的进行管理

4.2 具体实践

4.2.1 Skywalking+ Elasticsearch + Exceptionless

默认已经集成到个人微服务体系里了，可直接运行docker版本

4.2.2 Elasticsearch+ Logstash + Kibana

JAVA体系下的分布式监控与日志框架，可自行了解