标题微服务体系
- 微服务
1.1 基本概念
1.1.1 什么是微服务？
微服务架构是SOA思想某一种具体实现。是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并采用轻量级的通讯机制（TCP）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。
1.1.2 为什么要用微服务？
1.1.2.1 微服务解决了什么问题？
在微服务的最佳实践中都提到如果一个项目以微服务作为起点，则大概率会陷入项目失败。微服务的本质是解决了团队分工的问题，当项目团队的开发人员无法解决大型单体应用的问题或虽然可以解决问题但成本高昂的时候，微服务往往才是最佳实践。通过从外围不断拆分单体架构的业务，以细粒度的单项服务的形式发布服务，最终将单体架构微服务化。
1.1.2.2 微服务带来了什么挑战？
微服务首先是对组织架构的调整提出的新的挑战，微服务要求每一个服务尽可能的独立和内聚，这要求这个团队符合2pizza风格，也就是说每一个团队都尽可能的包含从开发到测试到运维人员组成的独立项目组。而不是传统大型企业中以横向切割的形式让开发、运维、测试各是一个独立部门。
微服务的第二个挑战是带来了分布式下开发、测试与运维的复杂性。微服务本质上并不是什么银弹，它解决了团队面对单体架构疲于奔命的开发和部署问题，但是也引来了新的问题。在单体开发过程中，开发人员不会想到方法调用会失败、会重试、要幂等。测试人员不会考虑几十个应用怎么一起集成测试，运维人员不会考虑下游应用挂了对我有什么影响。意识到分布式下开发、测试与运维的复杂性，并掌握这些复杂问题的方法才是更主要的。
1.2 架构设计
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)上传您的本地仓库中的镜像，但是由于国内已知的原因，还是推荐使用国内云提供商提供的免费镜像市场或者私有化部署自己的镜像仓库（推荐使用阿里云）
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: https://www.cnblogs.com/wenwei-blog/p/5861450.html
gitlab-runner: https://blog.csdn.net/weiguang1017/article/details/77720778
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体系下的分布式监控与日志框架，可自行了解
