文章 on ViatorLife Blog

Blazor WebApp Server&Cookie中AuthorizeAttribute的两重用途

Sat, 06 Dec 2025 10:00:00 +0800

框架说明

在使用Blazor WebApp Server模式下，设定以Cookie为鉴权机制。使用全局交互模式。

AuthorizeAttribute

在页面上标记AuthorizeAttribute。其作用在于设定该页面需要鉴权完毕才能访问。

@page "/counter"
@attribute [Microsoft.AspNetCore.Authorization.Authorize]

<PageTitle>Counter</PageTitle>

没有它，当为Http请求时如果没有全局开启授权检查，则能够直接响应页面内容和执行页面上的操作。当为SignalR时，也可直接响应页面内容且执行操作。为了区分使用场景，以下按照Http还是SignalR使用区分开描述。

Http请求

区分于是否启用了全局授权检查，其行为有所不同。

启用全局授权检查

在启用全局授权检查时，如下所示

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .RequireAuthorization(); //here

有些页面则需要标记匿名访问，比如Login Page。

@page "/login"
@layout EmptyLayout
@attribute [AllowAnonymous]

这种场景下，其他页面默认需要鉴权完毕才能访问。以Home为例

@page "/"
<PageTitle>Home</PageTitle>

<h1>Hello, world!</h1>

Welcome to your new app.

配置鉴权服务和使用Cookie Scheme

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.Cookie.Name = "auth_token";
        options.Cookie.MaxAge = TimeSpan.FromSeconds(15);
        options.LoginPath = "/login";
        options.AccessDeniedPath = "/access-denied";
    });
builder.Services.AddAuthorization();
builder.Services.AddCascadingAuthenticationState();

在请求Web时，默认为Home，应全局开启需要授权，则按照Cookie Scheme要求跳转到重定向页面，其效果如下：

不启用全局授权检查

直接在page上标记AuthorizeAttribute，则通过Http访问该页面时，仍然按照鉴权中间件配置的Cookie Scheme规则重定向到登录页。

比如Home页标记AuthorizeAttribute

Blazor WebApp Server&Cookie登出跨Tab下SignalR连接残留

Tue, 25 Nov 2025 10:00:00 +0800

框架说明

在使用Blazor WebApp Server模式下，设定以Cookie为鉴权机制，且所有页面都设定了Authorize特性。

问题陈述

当多开Tab页，其中一个Tab页执行退出操作，Cookie在浏览器中清除，可是其他Tab页仍然可以切换页面，执行请求。与传统Web程序工作机制不太相同。因其在首次访问页面后建立了SignalR信道连接，其通信过程中并不使用浏览器上存储的Cookie。

而当重新刷新Tab2或Tab3，则又立马跳转到登录页，因此时是走Http请求发起页面获取，没有Cookie。

总而言之便是，退出时无法跨Tab将其他页面一并退出，当前页面无法操作，其他页面仍然可以操作，其根源为无法清除SignalR信道内的Cookie信息。从通信方式上描述为如下场景，退出后只断掉了Http请求的鉴权检查，无法消除SignalR的通道。

解决方案

官方文档中提及了这种场景，也提供了方案来解决，需要自定义RevalidatingServerAuthenticationStateProvider类，这个类目的为服务端会按照其中属性值RevalidationInterval定期检查SignalR信道。

https://source.dot.net/#Microsoft.AspNetCore.Components.Server/Circuits/RevalidatingServerAuthenticationStateProvider.cs,14

其检查方法中，则可以根据当前信道内的信息去获取当前用户是否实际退出了，从而根据结果是断开SignalR信道还是仍然保持。

如下具体展开实现自定义类及应用。

新建项目

此处快速演示下其具体过程，搭建一个Server模式项目。启用全局交互模式

dotnet new blazor -n BlazorServerLogoutDemo -f net10.0 --interactivity Server --all-interactive true

修改App.razor，更换使用判断确定是哪种交互方式，以便于Login页使用表单发起Http请求。

...
<HeadOutlet @rendermode="PageRenderMode" />
...
<Routes @rendermode="PageRenderMode" />
...
@code {
    [CascadingParameter]
    private HttpContext HttpContext { get; set; } = default!;

    private IComponentRenderMode? PageRenderMode =>
        HttpContext.AcceptsInteractiveRouting() ? InteractiveServer : null;
}

设置鉴权授权

修改Program.cs，注册鉴权授权服务，增加鉴权授权中间件。

using BlazorServerLogoutDemo.Components;
using Microsoft.AspNetCore.Authentication.Cookies;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();
builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.Cookie.Name = "auth_token";
        options.Cookie.MaxAge = TimeSpan.FromMinutes(30);
        options.LoginPath = "/login";
        options.AccessDeniedPath = "/access-denied";
    });
builder.Services.AddAuthorization();
builder.Services.AddCascadingAuthenticationState();

var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error", createScopeForErrors: true);
    app.UseHsts();
}
app.UseHttpsRedirection();
app.UseAntiforgery();
app.MapStaticAssets();
app.UseAuthentication();
app.UseAuthorization();
app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode();
app.Run();

设置服务端模拟数据

本文简化登录页和退出操作，关注于同浏览器跨Tab访问操作，新增模拟数据页面。

Blazor WebApp-Server&AuthenticationSchemes报错

Wed, 15 Oct 2025 10:00:00 +0800

背景描述

集成到现有系统中，系统使用了Cookie作为鉴权方式，已有一个scheme正常业务使用。为接入开发工具，隔离现有scheme，另起一个DevTools Scheme，独立使用。集成Blazor为Blazor WebApp Server模式。

项目设置

在鉴权服务扩展，在已有scheme基础上扩展新scheme并简单设定其配置。

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        //...
    })
    .AddCookie("DevTools",options =>
    {
        options.Cookie.Name = "DevTools";
        options.Cookie.MaxAge = TimeSpan.FromMinutes(30);
        options.LoginPath = "/login";
        options.AccessDeniedPath = "/access-denied";
    })

Blazor页面设置Authorize特性，按照Blazor页面授权检查，在Blazor Page上标记Authorize。

@page "/counter"
@attribute [Authorize]
@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.Authorization

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p role="status">Current count: @currentCount</p>

从Authorize设定方式来讲，常规Asp.Net Core WebApi的用法应该也能够用于Blazor，因此设定如下方式。

@page "/counter"
@attribute [Authorize(AuthenticationSchemes = "DevTools")]
@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.Authorization

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p role="status">Current count: @currentCount</p>

调试该页面，未登录下能够按照Schemes要求正常跳转到登录页。

Blazor WebApp-Server&Cookie鉴权授权

Fri, 26 Sep 2025 10:00:00 +0800

Blazor WebApp-Server模式，借助于SignalR，能够令前端的一些操作移交到后端处理，本文仅简单介绍登录完成和鉴权授权过程。

新建项目

项目为Blazor WebApp-Server模板，没有启用全局交互模式，由各个页面自行设定交互方式。本文使用DotNet CLI快速搭建。

otnet new blazor -n ServerDemo -f net9.0 -int Server
dotnet new sln
dotnet sln add .\ServerDemo\

设置鉴权授权

和Asp.Net Core的鉴权授权方式相同，本文使用Cookie来作为schema。在服务注册时设定鉴权和授权配置，添加鉴权授权中间件。注册AddCascadingAuthenticationState服务，在组件间共享身份状态。

using Microsoft.AspNetCore.Authentication.Cookies;
using ServerDemo.Components;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();
builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.Cookie.Name = "auth_token";
        options.Cookie.MaxAge = TimeSpan.FromMinutes(30);
        options.LoginPath = "/login";
        options.AccessDeniedPath = "/access-denied";
    });
builder.Services.AddAuthorization();
builder.Services.AddCascadingAuthenticationState();

var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error", createScopeForErrors: true);
    app.UseHsts();
}
app.UseHttpsRedirection();
app.UseAntiforgery();
app.MapStaticAssets();
app.UseAuthentication();
app.UseAuthorization();
app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode();
app.Run();

创建登录页面

简单实现用户名密码验证登录页面，同时在本页面上进行Cookie生成。此处，点击表单提交，使用的是Http请求，服务端对应AuthenticateUserAsync方法处理，等同于WebApi机制，只是使用的是另一种Http Api机制。

Blazor WebAssembly&MudBlazor模板集成

Tue, 12 Aug 2025 10:00:00 +0800

MudBlazor组件库丰富且其组件名辨识度极高，UI设计上很不错。在纯Blazor WebAssembly Standalone模板上缺少了MudBlazor模板，因此集成时缺少参考文档。

新建项目

项目为Blazor WebAssembly Standalone模板。本文使用DotNet CLI快速搭建。

dotnet new blazorwasm -n AppDemo -f net9.0
dotnet new sln
dotnet sln add .\AppDemo\

集成MudBlazor包

只需一个包即可，样式文件和组件都在包中。

dotnet add package MudBlazor --version 8.14.0

服务注册

builder.Services.AddMudServices();

MudBlazor包方面完成了，接下来参照MudBlazor文档要求修改

删除原有所有css文件

默认Blazor WebAssembly Standalone模板wwwroot下为Bootstrap样式，可以全部移除，

修改index.html

替换Head

<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>AppDemo</title>
    <base href="/" />
    <link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500,700&display=swap" rel="stylesheet" />
    <link href="_content/MudBlazor/MudBlazor.min.css?v=1" rel="stylesheet" />
    <link rel="icon" type="image/png" href="favicon.png" />
</head>

替换Script

Blazor WebAssembly&JWT鉴权授权

Tue, 08 Jul 2025 10:00:00 +0800

前后端分离下，后端专注于业务逻辑，前端专注于页面交互，Blazor WebAssembly令后端开发者降低学习成本，也能够玩转一些前端开发功能。本文仅简单介绍前后端交互，借助于Blazor WebAssembly如何调用接口，鉴权授权。

新建项目

前端项目为Blazor WebAssembly(Standalone)模板，后端为WebApi。

本文使用DotNet CLI快速搭建。

dotnet new blazorwasm -n AppDemo -f net9.0
dotnet new webapi -n ApiDemo -f net9.0 -controllers
dotnet new sln
dotnet sln add .\AppDemo\
dotnet sln add .\ApiDemo\

服务端令牌接口

安装Nuget包

dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer

本次不使用数据库验证，直接模拟返回一个JWT。

[ApiController]
[Route("api/[controller]")]
public class AccountController : ControllerBase
{
    private const string SecretKey = "YourSuperSecretKeyThatIsAtLeast32CharactersLong!";
    private const string Issuer = "ApiDemo";
    private const string Audience = "ApiDemo";
    private const int ExpirationMinutes = 60;

    [Authorize]
    [HttpGet("CurrentUserName")]
    public string GetCurrentUserName()
    {
        return "admin";
    }

    [HttpPost("Login")]
    public IActionResult Login([FromBody] LoginRequest request)
    {
        // 示例：简单的硬编码验证（实际项目中应该从数据库验证）
        if (request.Username == "admin" && request.Password == "admin123")
        {
            var token = GenerateJwtToken(request.Username);
            var expires = DateTime.UtcNow.AddMinutes(ExpirationMinutes);

            return Ok(new LoginResponse
            {
                Token = token,
                Expires = expires
            });
        }

        return Unauthorized(new { message = "用户名或密码错误" });
    }

    private string GenerateJwtToken(string username)
    {
        var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(SecretKey));
        var credentials = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);

        var claims = new[]
        {
            new Claim(ClaimTypes.Name, username),
            new Claim(ClaimTypes.NameIdentifier, username),
            new Claim(JwtRegisteredClaimNames.Sub, username),
            new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString())
        };

        var token = new JwtSecurityToken(
            issuer: Issuer,
            audience: Audience,
            claims: claims,
            expires: DateTime.UtcNow.AddMinutes(ExpirationMinutes),
            signingCredentials: credentials
        );

        return new JwtSecurityTokenHandler().WriteToken(token);
    }
}

public class LoginRequest
{
    [Required(ErrorMessage = "用户名不能为空")]
    public required string Username { get; set; }

    [Required(ErrorMessage = "密码不能为空")]
    public required string Password { get; set; }
}

public class LoginResponse
{
    public string Token { get; set; } = string.Empty;
    public DateTime Expires { get; set; }
}

服务端鉴权配置

简单使用明文方式配置鉴权服务。设定默认Schema为Jwt格式。

Blazor WebAssembly&EdgeOne Pages部署记录

Thu, 19 Jun 2025 10:00:00 +0800

前言

对于Blazor WebAssembly，因其特殊性，可以直接部署成站点，浏览器下载后，在浏览器中直接运行，总想薅点羊毛，能够免费部署这类应用，搜寻一方了解到，像是Github Page、Azure Static App等都可以白嫖来部署静态站点。如此，结合部署过程，进行记录一番。

EdgeOne Pages

腾讯云提供的等同于Github Pages服务，目前阶段免费，可以部署静态站点和基于Next.js的全栈项目。

https://edgeone.cloud.tencent.com/pages/document/162936635171454976

新建项目

此处新建一个Blazor WebAssembly(Standalone)的项目，注意是非Blazor WebApp类型的。此处上传到Github中，因此Github中提前建好仓库，默认克隆到本地好了，开始创建项目。

// 假定路径
PS C:\demos\EdgeOnePagesBlazorDemo

执行创建命令

dotnet new blazorwasm -n EdgeOnePagesBlazorDemo -f net8.0 
dotnet new sln -n BlazorDemo
dotnet sln add .\EdgeOnePagesBlazorDemo\

增加gitignore忽略bin/obj等文件。

dotnet new gitignore

执行代码推送到Github仓库中，代码部分完事。

构建与部署

为了将站点资源打包后部署到EdgeOne Pages，需要做一步打包工作，借助于Github Actions完成打包。部署方式上有两种方案：

从EdgeOne Pages上配置由其主动拉取。
使用EdgeOne提供的CLI，将打包后的资源上传到EdgeOne Pages。

流水线构建

可以直接借助Github Pages一样的构建方式，新建yml来构建Blazor Wasm项目。在Github仓库页面上，点击顶部Action菜单，创建工作流，搜索.NET，点击配置按钮

更换默认文件名，具体名字随意

文件内容如下，各步骤见第一个参考文档内描述

# This workflow will build a .NET project
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-net

name: Deploy to Github Pages

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  deploy-to-github-pages:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Setup .NET
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: 8.0.x
    - name: Publish DotNet Blazor Project
      run: dotnet publish ./EdgeOnePageBlazorDemo/EdgeOnePageBlazorDemo.csproj -c Release -o release --nologo
    - name: Commit wwwroot to Github Pages
      uses: JamesIves/github-pages-deploy-action@3.7.1
      with:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        BRANCH: gh-pages
        FOLDER: release/wwwroot

保存开始执行流水线构建，正常构建完毕后，构建结果会存储在gh-pages分支中。再后续对main分支的改动都会触发流水线，并更新到gh-pages分支。如果Github Action运行中出现了403的错误信息，为配置中缺少权限。

Blazor WebAssembly&Github Page部署记录

Wed, 28 May 2025 10:00:00 +0800

前言

新建Github仓库

按照文档新建Github Pages的仓储 https://pages.github.com/

默认分支为main，先新建好一个gh-pages分支该分支用来存储静态站点文件。以避免后续main分支推了代码后不干净了。

新建项目

此处选择Blazor WebAssembly Standalone项目，非Blazor WebApp类型。

增加gitignore忽略bin/obj等文件。

dotnet new gitignore

创建完毕后推送代码到main，main分支用来存储源代码。

手动发布部署

先通过本地发布，将发布后的文件推送到分支，看效果，从而了解整个发布，部署过程。

本地发布

本地发布到文件夹

发布完毕后点击导航到文件夹中

后续部署只需要使用到wwwroot中的内容。

本地部署

新建gh-pages分支，这个分支用来存放Blazor资源文件，可以直接用于浏览器下载后访问的。复制出上一步发布后wwwroot内的文件到主目录下，剩余全部删除。

提交代码到gh-pages分支.

github设置中切换到gh-pages分支作为github pages的分支源头，切换完毕后等待，再访问仓库.github.io，例如我这的viatorlife.github.io，访问便可以看到blazor wasm应用了，尽管控制台报错，但确定是上去了。

修复问题

开始修复问题，gh-pages分支使用的默认的Github Action,不能够允许有_framework这种带下划线的文件夹，但可以增加一个空文件命名为.nojelly到gh-pages分支来去除检查，再等待后访问便恢复正常。

如果直接浏览器中输入url地址访问，会进入到404页面，因为Github Pages需要404.html

简单一点，复制index.html文件改名404.html即可。再访问便能够输入url进入到页面。

其余问题见参考文档中，此处只考虑这两个问题。

自动发布部署

如上是本地发布手动copy到gh-pages分支，再借助gh-pages分支的github action完成站点发布。这个过程可以借助Github Action来实现自动发布。

整个流程变更为如下：

本地推送代码到main分支
main: Github Action发布
产物推送到gh-pages分支
gh-pages: Github-Action发布
静态站点部署

点击顶部Action菜单，创建工作流，搜索.NET，选择

更换默认文件名，具体名字随意

文件内容如下，各步骤见第一个参考文档内描述

# This workflow will build a .NET project
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-net

name: Deploy ti Github Pages

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  deploy-to-github-pages:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Setup .NET
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: 8.0.x
    - name: Publish DotNet Blazor Project
      run: dotnet publish ./src/ViatorLife.Blog/ViatorLife.Blog.csproj -c Release -o release --nologo
    - name: Commit wwwroot to GitHub Pages
      uses: JamesIves/github-pages-deploy-action@3.7.1
      with:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        BRANCH: gh-pages
        FOLDER: release/wwwroot

如果Github Action运行中出现了403的错误信息，为配置中缺少权限，则参照打开权限即可。 https://juejin.cn/post/7195220128995213368

Blazor WebAssembly&Azure Static App部署记录

Mon, 26 May 2025 10:00:00 +0800

前言

新建项目

// 假定路径
PS C:\demos\ViatorLife.Blog>

执行创建命令

dotnet new blazorwasm -n ViatorLife.Blog -f net8.0 -o ./src/
dotnet new sln -n ViatorLife.Blog
dotnet sln add .\src\ViatorLife.Blog.csproj

增加gitignore忽略bin/obj等文件。

dotnet new gitignore

执行代码推送到Github仓库中，代码部分完事。

Azure部署

访问 https://portal.azure.com/ 登录 Azure，如果没有账户可以去注册一个。

选择资源组，填写名称，选择免费模式，以此薅羊毛。

选择仓库源，此处选择Github，找到仓库并选择分支后稍等几秒再往下挪，在生成预设中选择Blazor，会带出位置，但默认生成的应用位置(Client)不可用，修改将其对应于代码中的位置，改成仓库中BlazorWasm项目所在路径(src/ViatorLife.Blog)。纯部署Blazor wasm时不用管Api位置，直接删除API位置框中默认值。输出位置保持不变。

点击查看+创建，默认会生成好Github Action的yml到Github仓库中。用作流水线部署脚本。

进入到Github仓库中查看workflow，可见到app_location位置相对于代码中的csproj位置。

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v3
        with:
          submodules: true
          lfs: false
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_AMBITIOUS_CLIFF_0112DA81E }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "src/ViatorLife.Blog" # App source code path
          output_location: "wwwroot" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_AMBITIOUS_CLIFF_0112DA81E }}
          action: "close"

创建完毕后可在Github仓库中看到Github Action流水线正在执行中，执行完成便可以在Azure Static App中查看访问链接，直接点击便可看到效果。后续本地代码更改，推送到Github后，自动触发Github Action发布，发布完毕后自动更新静态站点，如此一来很方便薅羊毛。

ABP Framework-Blazor快速实践

Sat, 24 May 2025 10:00:00 +0800

前言

很多时候想要一个人快速搭建前端后端，但又不想基于MVC去自己写js开发页面，又或者使用SPA模板，写前端vue/angular/react代码，毕竟这块的学习成本还是有的，借助于Blazor，使用c#尽可能替代js，减少学习成本，并且blazor现在发展也稳定了，还有很多封装好的UI框架，省事许多。

ABP作为后端开发中强有力的框架，也集成好了Blazor作为前端框架，基础版使用了Blazorise作为UI框架，该UI框架可扩展多套CSS框架，诸如Bootstrap、AntDesign、

Material等。当然ABP也提供了更为丰富的LeptanX主题（https://www.leptontheme.com）但有点使用受限。基础版Blazorise的集成也足够满足开发需求了。

下载AbpCli

我需要使用DotNet8.0版本，对应ABP同级最新版本为8.3.4，因此下载Abp Cli 8.3.4版本。

dotnet tool install --global Volo.Abp.Cli --version 8.3.4

创建项目

创建基于Mysql，EfCore，Basic Theme(Blazorise),使用DotNet8.0的项目。此处使用不分层模板(AppNolayer)。

Blazor Server，具体为Blazor WebApp(Server)模式

abp new AbpBlazorDemo -t app-nolayers -u blazor-server -dbms MySQL -m none --theme basic -csf -v 8.3.4

Blazor WebAssembly，具体为Blazor WebApp(WebAssembly)模式

abp new AbpBlazorDemo -t app-nolayers -u blazor -dbms MySQL -m none --theme basic -csf -v 8.3.4

如想使用Auto模式（即运行时，先使用Server模式，等WebAssembly资产下载到浏览器后再使用WebAssembly模式）需要使用分层模板，也就是-t app。

abp new AbpBlazorDemo -t app -u blazor-webapp -dbms MySQL -m none --theme basic -csf -v 8.3.4

创建库表

更新appsettings.json中的连接字符串

Asp.Net Core Blazor&SignalR 后端消息推送

Sat, 12 Apr 2025 10:00:00 +0800

前言

为了能够将后台Job的进度同步前端，借助SignalR和BackgroundJob很方便完成同步。Blazor三种模式下，都能很方便的完成，并且无需引入js包，写前端代码，很是方便。

Blazor Server(WebApp)模式

新建项目，选择Blazor WebApp Server模式

增加Hub，连接前端和后端通信

public class MessageHub : Hub
{
    public async Task SendMessage(string message)
    {
        await Clients.All.SendAsync("ReceiveMessage", message);
    }
}

program.cs中增加端点

// Configure SignalR endpoint
app.MapHub<MessageHub>("/messageHub");

Blazor Server基于SignalR，所以不需要如下SignalR注册

builder.Services.AddSignalR();

添加Nuget包，该包用于前端页面处理SignalR。

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.SignalR.Client" Version="8.0.16" />
</ItemGroup>

新建Blazor页，需要注意请求路径需要与端点路径保持一致。

@page "/message"
@using Microsoft.AspNetCore.SignalR.Client
@implements IAsyncDisposable
@rendermode InteractiveServer
@inject NavigationManager NavigationManager

<PageTitle>Background Messages</PageTitle>

<h3>Background Messages</h3>

<div class="message-container">
    @foreach (var message in messages)
    {
        <div class="message">
            <span class="message-time">@message.TimeStamp.ToString("HH:mm:ss")</span>
            <span class="message-content">@message.Content</span>
        </div>
    }
</div>

<style>
    .message-container {
        max-height: 500px;
        overflow-y: auto;
        border: 1px solid #ddd;
        padding: 10px;
        margin-top: 20px;
    }

    .message {
        padding: 8px;
        margin-bottom: 8px;
        background-color: #f8f9fa;
        border-radius: 4px;
    }

    .message-time {
        color: #666;
        margin-right: 10px;
    }

    .message-content {
        color: #333;
    }
</style>

@code {
    private HubConnection? hubConnection;
    private List<MessageModel> messages = new();
    private const int MaxMessages = 100;

    protected override async Task OnInitializedAsync()
    {
        hubConnection = new HubConnectionBuilder()
            .WithUrl(NavigationManager.ToAbsoluteUri("/messageHub"))
            .WithAutomaticReconnect()
            .Build();

        hubConnection.On<string>("ReceiveMessage", (message) =>
        {
            messages.Insert(0, new MessageModel { Content = message, TimeStamp = DateTime.Now });
            if (messages.Count > MaxMessages)
            {
                messages.RemoveAt(messages.Count - 1);
            }
            InvokeAsync(StateHasChanged);
        });

        await hubConnection.StartAsync();
    }

    public async ValueTask DisposeAsync()
    {
        if (hubConnection is not null)
        {
            await hubConnection.DisposeAsync();
        }
    }

    private class MessageModel
    {
        public string Content { get; set; } = string.Empty;
        public DateTime TimeStamp { get; set; }
    }
}

如此，前后端通信即可配置完毕，接下来增加BackgroundJob，其内部发送消息，从而推送到前端展示。新增BackgroundJob

Asp.Net Core Blazor&Blazorise快速实践

Tue, 18 Mar 2025 10:00:00 +0800

前言

Blazor非常容易上手开发前端项目，结合一些封装好的UI框架更能省心省力。Blazorise（https://blazorise.com/）应用广。ABP中，默认接入了Blazorise，个人非常喜欢使用ABP完成，整个模块化设计巧妙，因此也想要从UI层面同步使用Blazorise。

Blazorise

皮肤（CSS 框架）和骨骼（C#实现UI组件）分离，皮肤支持 Bootstrap、Tailwind、Bulma、AntDesign、Fluent 2 和 Material 等 CSS 框架。Blazorise提供了众多常用的组件，基于这些组件，可以隔离具体使用的CSS框架。令开发人员只关注于UI展示与交互。

在官网中，提供了一些常用的构建块，能够节省不少开发工作。

https://blazorise.com/blocks

搭建Blazor项目

快速用命令行搭建Blazor WebApp(Server)项目。此处基于DotNet8.0

dotnet new blazor -f net8.0 -int Server -n BlazorServerBlazoriseDemo.App

接入Blazorise

参照Blazorise官方教程，此处简化几个步骤。

增加CSS框架

此处使用Bootstrap5和图标库

Install-Package Blazorise.Bootstrap5
Install-Package Blazorise.Icons.FontAwesome

还有其他包可以配套使用，除了Nuget包，还需要配合css和js文件，具体见官网使用。

AntDesign

Install-Package Blazorise.AntDesign
Install-Package Blazorise.Icons.FontAwesome

Bootstrap4

Install-Package Blazorise.Bootstrap
Install-Package Blazorise.Icons.FontAwesome

Bulma

Install-Package Blazorise.Bulma
Install-Package Blazorise.Icons.FontAwesome

FluentUI2

Install-Package Blazorise.FluentUI2
Install-Package Blazorise.Icons.FluentUI

Material

Install-Package Blazorise.Material
Install-Package Blazorise.Icons.Material

Tailwind

Install-Package Blazorise.Tailwind
Install-Package Blazorise.Icons.FontAwesome

配置css和js文件

因使用的DotNet8下WebApp的Server模式，在App.razor中删除存在的默认bootstrap.css和fontawesome文件，增加blazorise配套的系列css文件和js文件引用。

Asp.Net Core Blazor快速实践

Mon, 24 Feb 2025 10:00:00 +0800

Blazor 是一个使用 C# 和.NET 技术构建交互式 Web 应用的框架，它允许开发者在服务器端和客户端使用相同的语言进行开发，从而提高了开发效率和代码的可维护性。可以说是.NET生态系统中的一个革命性框架。Blazor的出现，让开发人员仅通过一种编程语言，就可以实现前后端的全栈开发，很是方便。

优势所在

使用C#代替JavaScript来创建信息丰富的交互式UI。
共享使用.NET编写的服务器端和客户端应用逻辑。
将UI呈现为HTML和CSS，以支持众多浏览器，其中包括移动浏览器。
与新式托管平台（如Docker）集成。

托管模式

DotNet8.0后统一成如下两种模式，各自应用于不同的场景。

Blazor Web App项目模板：应用程序在服务器端运行，并使用SignalR实时通讯框架与浏览器进行交互。
- None(Static SSR)，纯静态服务器呈现模板
- Server(Interactive Server)，交互式呈现模板，后端渲染
- WebAssembly(Interactive WebAssembly)，从服务端下载完WebAssembly后使用WebAssembly在浏览器中运行
- Auto(Interactive Auto)，先使用Server模式，下载完WebAssembly后使用WebAssembly在浏览器中运行
独立 Blazor WebAssembly 应用项目模板：应用程序直接在客户端的WebAssembly中运行，允许C#代码在浏览器中执行，不依赖服务器。

新建项目

新建Blazor Server项目，此处以命令行形式创建，DotNet8.0, Server模式

dotnet new blazor -f net8.0 -int Server -n BlazorServerDemo.App

其项目结构中，包含

Layout 文件夹：包含以下布局组件和样式表：
- MainLayout 组件 (MainLayout.razor)：应用的布局组件。
  - MainLayout.razor.css：应用主布局的样式表。
- NavMenu 组件 (NavMenu.razor)：实现边栏导航。包括 NavLink 组件 (NavLink)，该组件可向其他 Razor 组件呈现导航链接。 NavLink 组件会在系统加载其组件时自动指示选定状态，这有助于用户了解当前显示的组件。
  - NavMenu.razor.css：应用导航菜单的样式表。
Pages 文件夹：包含 Blazor 应用的可路由 Razor 组件 (.razor)。每个页面的路由都是使用 @page 指令指定的。该模板包括以下组件：

DotNet&Coverlet统计单元测试覆盖率

Sun, 12 Jan 2025 10:00:00 +0800

前言

代码覆盖率是衡量代码质量的一个指标。较高的代码覆盖率能够显著提升开发者对代码的信心。从逻辑层面来看，代码经过的测试越详尽、越全面，其存在漏洞的概率也就越低。毕竟，在软件开发的实际过程中，要实现一个完全没有任何漏洞的项目，这几乎是一个难以企及的乌托邦式理想。

Coverlet

在日常开发中，像 Visual Studio、Rider 这类常用的集成开发环境（IDE），能够直接查看代码覆盖率。然而，若要将覆盖率管控纳入自动化的质量管控流程，例如 Github Actions、Azure Devops、Github CI 以及 Sonarqube 等系统时，就需要额外开展一些工作。在这种情况下，开源项目 Coverlet(https://github.com/coverlet-coverage/coverlet) 能够发挥重要作用，帮助我们实现这一目标。

更换默认包

默认场景下，xUnit测试项目自带的包为coverlet.collector

在如下示例中，我将使用coverlet.msbuild包(https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/MSBuildIntegration.md)，因此只装coverlet.msbuild包，新建单元测试项目时，将默认使用的包coverlet.collector删除。

ReportGenerator

https://github.com/danielpalme/ReportGenerator

生成漂亮的报告，需要全局安装，这个包可以将coverlet生成的文件转换成精美的图表文档。

dotnet tool install -g dotnet-reportgenerator-globaltool

使用时只需指定文件执行即可

reportgenerator -reports:coverage.opencover.xml -targetdir:report

在当前目录下会创建report文件夹，其中index.html为更加明了易懂的报表文档。

示例

新建项目

新建xUnit的测试项目ReportTestDemo.Tests，此处使用DotNet6.0，该项目中同时存在被测类和测试代码，如下移除默认包，增加coverlet.msbuild包。

mkdir ReportTestDemo
cd ReportTestDemo
dotnet new xunit -n ReportTestDemo.Tests --framework net6.0
dotnet add .\ReportTestDemo.Tests\ package coverlet.msbuild --version 6.0.4
dotnet remove .\ReportTestDemo.Tests\ package coverlet.collector

新建被测类和测试代码类

// OrderService.cs
namespace ReportTestDemo.Tests;


public class OrderService
{
    public int GetCurrentValue()
    {
        return 1;
    }


    public int GetExpectedValue()
    {
        return 1;
    }
}


// OrderServiceUnitTest.cs
namespace ReportTestDemo.Tests;


[ExcludeFromCodeCoverage]
public class OrderServiceUnitTest
{
    [Fact]
    public void Test1()
    {
        var orderService = new OrderService();
        Assert.Equal(orderService.GetCurrentValue(), orderService.GetExpectedValue());
    }
}

执行测试

执行命令运行测试，当前目录下生成了coverage.opencover.xml文件。

ABP Framework-EventBus源码解析

Thu, 26 Dec 2024 10:00:00 +0800

https://abp.io/docs/6.0/Event-Bus

Version

6.0.3

Package

Volo.Abp.EventBus.Abstractions
Volo.Abp.EventBus //依赖Volo.Abp.EventBus.Abstractions
Volo.Abp.EventBus.Azure //依赖Volo.Abp.EventBus
Volo.Abp.EventBus.Kafka //依赖Volo.Abp.EventBus
Volo.Abp.EventBus.RabbitMQ //依赖Volo.Abp.EventBus
Volo.Abp.EventBus.Rebus //依赖Volo.Abp.EventBus

EventHandler

当某个事件发生，如果想要订阅事件，则是定义一个Handler来处理，ABP中经常使用的模式简要如下，以本地事件为例：

public class MyHandler : ILocalEventHandler<StockCountChangedEvent>, ITransientDependency
{
 public async Task HandleEventAsync(StockCountChangedEvent eventData)
 {
 //TODO: your code that does something on the event
 }
}

EventHandler从源头上便区分为LocalHandler和DistributedHandler以应付不同的使用场景。在项目启动阶段，在AbpEventBusModule中，会扫描所有LocalEventHandler和DistributedEventHandler分别注册到AbpLocalEventBusOptionsh和AbpDistributedEventBusOptions。

[DependsOn(
    typeof(AbpEventBusAbstractionsModule),
    typeof(AbpMultiTenancyModule),
    typeof(AbpJsonModule),
    typeof(AbpGuidsModule),
    typeof(AbpBackgroundWorkersModule),
    typeof(AbpDistributedLockingAbstractionsModule)
    )]
public class AbpEventBusModule : AbpModule
{
    public override void PreConfigureServices(ServiceConfigurationContext context)
    {
        AddEventHandlers(context.Services);
    }


    //...


    private static void AddEventHandlers(IServiceCollection services)
    {
        var localHandlers = new List<Type>();
        var distributedHandlers = new List<Type>();


 // 扫描项目中的Handlers
        services.OnRegistred(context =>
        {
            if (ReflectionHelper.IsAssignableToGenericType(context.ImplementationType, typeof(ILocalEventHandler<>)))
            {
                localHandlers.Add(context.ImplementationType);
            }
            else if (ReflectionHelper.IsAssignableToGenericType(context.ImplementationType, typeof(IDistributedEventHandler<>)))
            {
                distributedHandlers.Add(context.ImplementationType);
            }
        });

 // 存储LocalHandlers和DistributedHandlers到各自Options中
        services.Configure<AbpLocalEventBusOptions>(options =>
        {
            options.Handlers.AddIfNotContains(localHandlers);
        });
        services.Configure<AbpDistributedEventBusOptions>(options =>
        {
            options.Handlers.AddIfNotContains(distributedHandlers);
        });
    }
}

这两个Options将贯穿后续EventBus。

ABP Framework-EmailSending源码解析

Fri, 08 Nov 2024 10:00:00 +0800

https://abp.io/docs/6.0/Emailing

Version

6.0.3

Package

Volo.Abp.Emailing

其组件包为

Volo.Abp.MailKit

在Volo.Abp.Emailing中本身具有SmtpClient，这是微软提供的，如果可以满足使用，可以不需要在加入Volo.Abp.MailKit包。

IEmailSender

其核心接口如下，其中Queue方法目的是用来做延迟发送，走BackgroundJob，再BackgroundJob中再调用IEmailSender的SendAsync方法发送。

public interface IEmailSender
{
    /// <summary>
    /// Sends an email.
    /// </summary>
    Task SendAsync(
        string to,
        string? subject,
        string? body,
        bool isBodyHtml = true,
        AdditionalEmailSendingArgs? additionalEmailSendingArgs = null
    );


    /// <summary>
    /// Sends an email.
    /// </summary>
    Task SendAsync(
        string from,
        string to,
        string? subject,
        string? body,
        bool isBodyHtml = true,
        AdditionalEmailSendingArgs? additionalEmailSendingArgs = null
    );


    /// <summary>
    /// Sends an email.
    /// </summary>
    /// <param name="mail">Mail to be sent</param>
    /// <param name="normalize">
    /// Should normalize email?
    /// If true, it sets sender address/name if it's not set before and makes mail encoding UTF-8.
    /// </param>
    Task SendAsync(
        MailMessage mail,
        bool normalize = true
    );


    /// <summary>
    /// Adds an email to queue to send via background jobs.
    /// </summary>
    Task QueueAsync(
        string to,
        string subject,
        string body,
        bool isBodyHtml = true,
        AdditionalEmailSendingArgs? additionalEmailSendingArgs = null
    );


    /// <summary>
    /// Adds an email to queue to send via background jobs.
    /// </summary>
    Task QueueAsync(
        string from,
        string to,
        string subject,
        string body,
        bool isBodyHtml = true,
        AdditionalEmailSendingArgs? additionalEmailSendingArgs = null
    );
}

其接口实现部分类图如下。 Volo.Abp.Emailing库中包含了EmailSenderBase类，提供了一个核心的抽象方法SendEmailAsync

ABP Framework-ExceptionHanding源码解析

Fri, 25 Oct 2024 10:00:00 +0800

https://abp.io/docs/6.0/Exception-Handling

Version

6.0.3

Package

Volo.Abp.ExceptionHandling

AspNetCore异常体系

Abp的异常体系基于Asp.Net Core的异常体系，后者简要概括分为两部分，第一个是全局异常处理即ExceptionHandlingMiddleware,还有一个是Mvc middleware中的ExceptionFilter，这部分可以参考文档：

https://learn.microsoft.com/zh-cn/aspnet/core/fundamentals/error-handling?view=aspnetcore-8.0

https://learn.microsoft.com/zh-cn/aspnet/core/web-api/handle-errors?view=aspnetcore-8.0

https://source.dot.net/#BasicWebSite/Filters/TestExceptionFilter.cs,9

Abp异常体系

Abp异常处理

Abp在AspNetCore的基础上增加了与之对应的类，一个是AbpExceptionHandlingMiddleware.cs和AbpExceptionFilter.cs，其异常处理思路是一致的，当Controller/Action中出现异常时，AbpExceptionFilter先处理，如下代码所示

protected virtual async Task HandleAndWrapException(ExceptionContext context)
{
    var exceptionHandlingOptions = context.GetRequiredService<IOptions<AbpExceptionHandlingOptions>>().Value;


 //异常信息转换为错误信息
    var exceptionToErrorInfoConverter = context.GetRequiredService<IExceptionToErrorInfoConverter>();
    var remoteServiceErrorInfo = exceptionToErrorInfoConverter.Convert(context.Exception, options =>
    {
        options.SendExceptionsDetailsToClients = exceptionHandlingOptions.SendExceptionsDetailsToClients;
        options.SendStackTraceToClients = exceptionHandlingOptions.SendStackTraceToClients;
    });


 //记录异常信息日志
    var logLevel = context.Exception.GetLogLevel();
    var remoteServiceErrorInfoBuilder = new StringBuilder();
    remoteServiceErrorInfoBuilder.AppendLine($"---------- {nameof(RemoteServiceErrorInfo)} ----------");
    remoteServiceErrorInfoBuilder.AppendLine(context.GetRequiredService<IJsonSerializer>().Serialize(remoteServiceErrorInfo, indented: true));
    var logger = context.GetService<ILogger<AbpExceptionFilter>>(NullLogger<AbpExceptionFilter>.Instance);
    logger.LogWithLevel(logLevel, remoteServiceErrorInfoBuilder.ToString());
    logger.LogException(context.Exception, logLevel);


 //异常信息消息通知
    await context.GetRequiredService<IExceptionNotifier>().NotifyAsync(new ExceptionNotificationContext(context.Exception));


 //异常错误码转换
    if (context.Exception is AbpAuthorizationException)
    {
        await context.HttpContext.RequestServices.GetRequiredService<IAbpAuthorizationExceptionHandler>()
            .HandleAsync(context.Exception.As<AbpAuthorizationException>(), context.HttpContext);
    }
    else
    {
        context.HttpContext.Response.Headers.Add(AbpHttpConsts.AbpErrorFormat, "true");
        context.HttpContext.Response.StatusCode = (int)context
            .GetRequiredService<IHttpExceptionStatusCodeFinder>()
            .GetStatusCode(context.HttpContext, context.Exception);


        context.Result = new ObjectResult(new RemoteServiceErrorResponse(remoteServiceErrorInfo));
    }


 //标识异常被处理
    context.Exception = null; //Handled!
}

其中核心类为IExceptionToErrorInfoConverter和IHttpExceptionStatusCodeFinder，通过对应实现来将不同类型的异常转换成对应的错误信息以及响应的状态码，如Abp的UserFriendlyException便是在这其中处理从而有403的状态码。

ABP Framework-Cache源码解析

Mon, 16 Sep 2024 10:00:00 +0800

https://abp.io/docs/6.0/Caching

Version

6.0.3

Package

Volo.Abp.Caching

基于Redis的缓存包

Volo.Abp.Caching.StackExchangeRedis

Abp的缓存包作为基础模块，在Abp模板中被很多模块所依赖，因此开发中，一般不用手动加入AbpCachingModule，但对于Redis的module，需要手动加入模块依赖中。

缓存实现

ABP的缓存其本质上还是借助于Asp.Net Core的缓存接口与实现，包括IMemoryCache和IDistributedCache，从Abp.Caching的模块中可见

[DependsOn(
    typeof(AbpThreadingModule),
    typeof(AbpSerializationModule),
    typeof(AbpUnitOfWorkModule),
    typeof(AbpMultiTenancyModule),
    typeof(AbpJsonModule))]
public class AbpCachingModule : AbpModule
{
    public override void ConfigureServices(ServiceConfigurationContext context)
    {
        context.Services.AddMemoryCache();
        context.Services.AddDistributedMemoryCache();


 //...
 }
}

了解Asp.Net Core中的缓存

在该缓存上，ABP设计了IDistributedCache<,>, 提供了一些额外的方法扩展使用场景，如下简要列出几个方法。

public interface IDistributedCache<TCacheItem, TCacheKey>
    where TCacheItem : class
{
    Task<TCacheItem?> GetAsync();
    Task<KeyValuePair<TCacheKey, TCacheItem?>[]> GetManyAsync();
    Task<TCacheItem?> GetOrAddAsync();
    Task<KeyValuePair<TCacheKey, TCacheItem?>[]> GetOrAddManyAsync();


    Task SetAsync();
    Task SetManyAsync();
    Task RefreshAsync();
    Task RefreshManyAsync();
 Task RemoveAsync();
    Task RemoveManyAsync();
}

该部分类图如下 IDistributedCache实则是指定了Key类型为String的IDistributedCache<TCacheItem,TCacheKey>。

ABP Framework-Blob Storage源码解析

Tue, 13 Aug 2024 10:00:00 +0800

https://abp.io/docs/6.0/Blob-Storing

Version

6.0.3

Package

Volo.Abp.BlobStoring
Volo.Abp.BlobStoring.Aliyun
Volo.Abp.BlobStoring.Aws
Volo.Abp.BlobStoring.Azure
Volo.Abp.BlobStoring.FileSystem
Volo.Abp.BlobStoring.Minio


//独立模块
Volo.Abp.BlobStoring.Database.*

BlobProvider

当有一个Blob需要存储到存储介质上，因为存储介质各有不同，调用每一个存储介质的方式有所差异，ABP在各式各样的存储介质上抽象一层，提供基础方法来确保对于Blob的常规操作，如存储，查询，删除，判断是否存在等方法。代码简要如下

public interface IBlobContainer
{
    Task SaveAsync(string name, Stream stream, bool overrideExisting = false);
    Task<bool> DeleteAsync(string name);
    Task<bool> ExistsAsync(string name);
    Task<Stream> GetAsync(string name);
    Task<Stream> GetOrNullAsync(string name);
}

同时提供了Azure/Aws/Aliyun/File/Db/Minio等且支持扩展的Provider，来隔离实际的调用方式。在不同的存储介质下，调用不同的包，此处以Minio为例，在MinioBlobProvider(Volo.Abp.BlobStoring.Minio包)中，依赖Minio包，将Blob移交到Minio的参数下。代码简要如下

public class MinioBlobProvider : BlobProviderBase, ITransientDependency
{
 //...
    public override async Task SaveAsync(BlobProviderSaveArgs args)
    {
        var blobName = MinioBlobNameCalculator.Calculate(args);


 // 生成MinioClient
        var client = GetMinioClient(args);
        var containerName = GetContainerName(args);


        //...


 // 上传Blob到Minio中
        await client.PutObjectAsync(containerName, blobName, args.BlobStream, args.BlobStream.Length);
    }


    public override async Task<bool> DeleteAsync(BlobProviderDeleteArgs args)
    {
        var blobName = MinioBlobNameCalculator.Calculate(args);


 // 生成MinioClient
        var client = GetMinioClient(args);
        var containerName = GetContainerName(args);


 // 请求Minio删除文件
        if (await BlobExistsAsync(client, containerName, blobName))
        {
            await client.RemoveObjectAsync(containerName, blobName);
            return true;
        }


        return false;
    }


    public override async Task<bool> ExistsAsync(BlobProviderExistsArgs args)
    {
        var blobName = MinioBlobNameCalculator.Calculate(args);


 // 生成MinioClient
        var client = GetMinioClient(args);
        var containerName = GetContainerName(args);


 // 请求Minio查询文件是否存在
 try
 {
        await client.StatObjectAsync(containerName, blobName);
 }
 catch(Exception)
 {
 return false;
 }

 return true;
    }


 //...
    protected virtual MinioClient GetMinioClient(BlobProviderArgs args)
    {
        var configuration = args.Configuration.GetMinioConfiguration();


        var client = new MinioClient()
            .WithEndpoint(configuration.EndPoint)
            .WithCredentials(configuration.AccessKey, configuration.SecretKey);


        if (configuration.WithSSL)
        {
            client.WithSSL();
        }


        return client.Build();
    }
 //...
/   
}

对于其他Provider来讲，大致过程相同。参照同样的过程，可以扩展需要的存储介质Provider。

ABP Framework-Feature源码解析

Fri, 05 Jul 2024 10:00:00 +0800

https://abp.io/docs/6.0/Features

Version

6.0.3

Package

Volo.Abp.Features


//独立模块
Volo.Abp.FeatureManagement.*

FeatureDefinitionProvider

内容定义

在每个module中都可以定义Feature，遵从如下示例格式

public class MyFeatureDefinitionProvider : FeatureDefinitionProvider
{
 public override void Define(IFeatureDefinitionContext context)
 {
 var myGroup = context.AddGroup("MyApp");


 myGroup.AddFeature("MyApp.PdfReporting", defaultValue: "false");
 myGroup.AddFeature("MyApp.MaxProductCount", defaultValue: "10");
 }
}

在AbpFeaturesModule中，基类FeatureDefinitionProvider在预初始化时会被扫描到。

[DependsOn(
    typeof(AbpLocalizationModule),
    typeof(AbpMultiTenancyModule),
    typeof(AbpValidationModule),
    typeof(AbpAuthorizationAbstractionsModule)
    )]
public class AbpFeaturesModule : AbpModule
{
    public override void PreConfigureServices(ServiceConfigurationContext context)
    {
        context.Services.OnRegistred(FeatureInterceptorRegistrar.RegisterIfNeeded);
        AutoAddDefinitionProviders(context.Services);
    }

 //...

    private static void AutoAddDefinitionProviders(IServiceCollection services)
    {
        var definitionProviders = new List<Type>();


 // 收集所有继承自IFeatureDefinitionProvider的类
        services.OnRegistred(context =>
        {
            if (typeof(IFeatureDefinitionProvider).IsAssignableFrom(context.ImplementationType))
            {
                definitionProviders.Add(context.ImplementationType);
            }
        });


 // 将所有SettingDefinitionProvider保存到AbpFeatureOptions中
        services.Configure<AbpFeatureOptions>(options =>
        {
            options.DefinitionProviders.AddIfNotContains(definitionProviders);
        });
    }
}

如上需要注意AbpFeatureOptions，所有的FeatureDefinitionProvider最终汇总到其内部的集合中，同时查看该类可知也存储着不同值来源的FeatureValueProvider。

ABP Framework-Setting源码解析

Fri, 28 Jun 2024 10:00:00 +0800

https://abp.io/docs/6.0/Settings

Version

6.0.3

Package

Volo.Abp.Settings


//独立模块
Volo.Abp.SettingManagement.*

SettingDefinitionProvider

内容定义

在每个module中都可以定义Setting，遵从如下示例格式

public class YourSettingDefinitionProvider : SettingDefinitionProvider
{
 public override void Define(ISettingDefinitionContext context)
 {
 context.Add(
 new SettingDefinition("Smtp.Host", "127.0.0.1"),
 new SettingDefinition("Smtp.Port", "25"),
 new SettingDefinition("Smtp.UserName"),
 new SettingDefinition("Smtp.Password", isEncrypted: true),
 new SettingDefinition("Smtp.EnableSsl", "false")
 );
 }
}

在AbpSettingModule中，基类SettingDefinitionProvider在预初始化时会被扫描到。

[DependsOn(
    typeof(AbpLocalizationAbstractionsModule),
    typeof(AbpSecurityModule),
    typeof(AbpMultiTenancyModule)
    )]
public class AbpSettingsModule : AbpModule
{
    public override void PreConfigureServices(ServiceConfigurationContext context)
    {
        AutoAddDefinitionProviders(context.Services);
    }


 //...


    private static void AutoAddDefinitionProviders(IServiceCollection services)
    {
        var definitionProviders = new List<Type>();


 // 收集所有继承自ISettingDefinitionProvider的类
        services.OnRegistred(context =>
        {
            if (typeof(ISettingDefinitionProvider).IsAssignableFrom(context.ImplementationType))
            {
                definitionProviders.Add(context.ImplementationType);
            }
        });


 // 将所有SettingDefinitionProvider保存到AbpSettingOptions中
        services.Configure<AbpSettingOptions>(options =>
        {
            options.DefinitionProviders.AddIfNotContains(definitionProviders);
        });
    }
}

如上需要注意AbpSettingOptions，所有的SettingDefinitionProvider最终汇总到其内部的集合中，同时查看该类可知也存储着不同值来源的SettingValueProvider。

ABP Framework-MultiTenancy源码解析

Sun, 19 May 2024 10:00:00 +0800

https://abp.io/docs/6.0/Multi-Tenancy

Version

6.0.3

Package

Volo.Abp.AspNetCore.MultiTenancy
Volo.Abp.MultiTenancy


//独立模块
Volo.Abp.TenantManagement.*

多租户中间件

如想要使用上多租户，中间件是必不可少的一部分，MultiTenancyMiddleware.cs。

请求进入后，首先进行的是租户解析，简要查看租户中间件源码，省略与简化后如下：

public class MultiTenancyMiddleware : IMiddleware, ITransientDependency
{
   public async Task InvokeAsync(HttpContext context, RequestDelegate next)
    {
 // 从请求信息中解析拿到租户信息
        var tenant = await _tenantConfigurationProvider.GetAsync(saveResolveResult: true);

 // 如果是新租户则切换上下文
 if (tenant?.Id != _currentTenant.Id)
        {
 // 更新当前租户
            using (_currentTenant.Change(tenant?.Id, tenant?.Name))
            {
                if (_tenantResolveResultAccessor.Result != null &&
                    _tenantResolveResultAccessor.Result.AppliedResolvers.Contains(QueryStringTenantResolveContributor.ContributorName))
                {
 // 租户信息记录到Cookie中
                    AbpMultiTenancyCookieHelper.SetTenantCookie(context, _currentTenant.Id, _options.TenantKey);
                }


 // 下一个中间件
                await next(context);
            }
        }
        else
        {
 // 下一个中间件
            await next(context);
        }
 }
}

如上核心部分几个抽象接口：

ABP Framework-BackgroundJob源码解析

Fri, 05 Apr 2024 10:00:00 +0800

https://abp.io/docs/6.0/Background-Jobs

Version

6.0.3

Package

Volo.Abp.BackgroundJobs.HangFire //依赖Hangfire和Volo.Abp.BackgroundJobs.Abstractions
Volo.Abp.BackgroundJobs.Quartz //依赖Quartz和Volo.Abp.BackgroundJobs.Abstractions
Volo.Abp.BackgroundJobs.RabbitMQ //依赖RabbitMQ和Volo.Abp.BackgroundJobs.Abstractions
Volo.Abp.BackgroundJobs //依赖BackgroundWorker和Volo.Abp.BackgroundJobs.Abstractions，与上第三方组件平级
Volo.Abp.BackgroundJobs.Abstractions


//独立模块
Volo.Abp.BackgroundJobs.Domain
Volo.Abp.BackgroundJobs.Domain.Shared
Volo.Abp.BackgroundJobs.EntityFrameworkCore
Volo.Abp.BackgroundJobs.MongoDB

BackgroundJob

JobArgs

作为最小执行单元，使用时只需继承BackgroundJob或AsyncBackgroundJob。

public class EmailSendingJob : AsyncBackgroundJob<EmailSendingArgs>, ITransientDependency
{
 private readonly IEmailSender _emailSender;


 public EmailSendingJob(IEmailSender emailSender)
 {
 _emailSender = emailSender;
 }


 public override async Task ExecuteAsync(EmailSendingArgs args)
 {
 await _emailSender.SendAsync(args.EmailAddress, args.Subject, args.Body);
 }
}

前提是需要一个JobArgs，来传递Job执行需要的一些参数。

public class EmailSendingArgs
{
 public string EmailAddress { get; set; }
 public string Subject { get; set; }
 public string Body { get; set; }
}

文档中提到BackgroundJobName，在代码中体现为BackgroundJobNameAttribute。实则是在当使用了RabbitMQ或者类似的第三方组件时才需要拿到名字作为队列名，如果在Hangfire或者Quartz或者ABP自身的BackgroundJobWorker管理，都无需要使用到BackgroundJobNameAttribute。当然如果加上了，也没有影响，只是加入Job时，会以加上的名字作为Job名，加入到执行队列中。以DefaultBackgroundJobManager为例

ABP Framework-BackgroundWorker源码解析

Sun, 17 Mar 2024 10:00:00 +0800

https://abp.io/docs/6.0/Background-Workers

Version

6.0.3

Package

Volo.Abp.BackgroundWorkers.Hangfire //依赖Hangfire和Volo.Abp.BackgroundWorkers
Volo.Abp.BackgroundWorkers.Quartz //依赖Quartz和Volo.Abp.BackgroundWorkers
Volo.Abp.BackgroundWorkers

BackgroundWorker

和BackgroundJob不同，Worker更多在后台定期的工作，Job更多的是特定时间执行。

在源码中，IBackgroundWorker作为抽象，承担BackgroundWorkerManager和具体的BackgroundWork执行间的衔接，并且确定所有的Worker都为单例。

public interface IBackgroundWorker : IRunnable, ISingletonDependency
{
}

BackgroundWorkerBase

在BackgroundWorkerBase也没有实际的处理，只是封装了下Logger服务和ServiceProvider，以便于在单例的Worker中使用IOC服务。

public abstract class BackgroundWorkerBase : IBackgroundWorker
{
    public IAbpLazyServiceProvider LazyServiceProvider { get; set; }
    public IServiceProvider ServiceProvider { get; set; }
    protected ILoggerFactory LoggerFactory => LazyServiceProvider.LazyGetRequiredService<ILoggerFactory>();
    protected ILogger Logger => LazyServiceProvider.LazyGetService<ILogger>(provider => LoggerFactory?.CreateLogger(GetType().FullName) ?? NullLogger.Instance);


    public virtual Task StartAsync()
    {
        Logger.LogDebug("Started background worker: " + ToString());
        return Task.CompletedTask;
    }


    public virtual Task StopAsync()
    {
        Logger.LogDebug("Stopped background worker: " + ToString());
        return Task.CompletedTask;
    }


    public override string ToString()
    {
        return GetType().FullName;
    }
}

当项目中需要定义Worker时，直接继承BackgroundWorkerBase，这类Worker在应用程序启动时调用Start，应用关闭时调用Stop，使用场景较少。

ABP Framework-Permission&Authorization源码解析

Tue, 20 Feb 2024 10:00:00 +0800

https://abp.io/docs/6.0/Authorization

前提了解

https://learn.microsoft.com/zh-cn/aspnet/core/security/authorization/policies?view=aspnetcore-8.0

ABP基于Asp.Net Core的授权检查与权限声明体系，使用[AuthorizeAttribute]，而对于Asp.Net Core的权限声明简要描述下：

Controller/Action上加AuthorizeAttribute,使用Role或Policy来限制方法的访问。
请求到达时，Authorize判断前提默认为鉴权通过的标记了IsAuthenticated。其次会按照Role或Policy，从当前请求的HttpContext中或者查询数据库/服务中，拿到有关信息，如果符合Role或Policy则授权检查通过。
请求方法，执行逻辑，返回结果。

一般场景很少直接使用Role，并且此文基于ABP的实践，采用ABP中的权限定义来作为Policy，具体便是，方法上标记Policy=PermissionDefinition.XXXName。在授权检查时，查询当前人的角色或自身具备了该权限，则授权检查通过。

Version

6.0.3

Package

Volo.Abp.Authorization
Volo.Abp.Authorization.Abstractions


//独立模块
Volo.Abp.PermissionManagement.*

权限定义

权限定义树

在各垂直业务的独立模块中，一般会定义各自的权限定义树，比如User/Tenant等，也比如订单模块，地址模块等，都会在模块内构建好自身的权限定义树。

public static class WorkSpacePermissions
{
    public const string GroupName = "WorkSpaceManagement";


    public static class Projects
    {
        public const string Default = GroupName + ".Projects";
        public const string Create = Default + ".Create";
        public const string Update = Default + ".Update";
        public const string Delete = Default + ".Delete";
        public const string ManageTypes = Default + ".ManageTypes";


        public static class Members
        {
            public const string Default = Projects.Default + ".Members";
            public const string Create = Default + ".Create";
            public const string Update = Default + ".Update";
            public const string Delete = Default + ".Delete";
            public const string ManageRoles = Default + ".ManageRoles";
            public const string ManageInvites = Default + ".ManageInvites";
        }
    }
}


public class WorkSpacePermissionDefinitionProvider : PermissionDefinitionProvider
{
 public override void Define(IPermissionDefinitionContext context)
 {
     var projectsPermission = workSpaceGroup.AddPermission(WorkSpacePermissions.Projects.Default);
     projectsPermission.AddChild(WorkSpacePermissions.Projects.Create);
     projectsPermission.AddChild(WorkSpacePermissions.Projects.Update);
     projectsPermission.AddChild(WorkSpacePermissions.Projects.Delete);
     projectsPermission.AddChild(WorkSpacePermissions.Projects.ManageTypes);

     var projectMembersPermission = projectsPermission.AddChild(WorkSpacePermissions.Projects.Members.Default);
     projectMembersPermission.AddChild(WorkSpacePermissions.Projects.Members.Create);
     projectMembersPermission.AddChild(WorkSpacePermissions.Projects.Members.Update);
     projectMembersPermission.AddChild(WorkSpacePermissions.Projects.Members.Delete);
     projectMembersPermission.AddChild(WorkSpacePermissions.Projects.Members.ManageRoles);
     projectMembersPermission.AddChild(WorkSpacePermissions.Projects.Members.ManageInvites);
 }
}

可以构建多级权限（顶级Group不参与权限）只用来权限分组。在ABP6.0版本，该部分权限定义不会持久化到数据库中，此处仅以6.0版本为主（8.0会持久化）。 IPermissionDefinitionProvider中定义了如下三个接口，但使用频繁的还是Define

ABP Framework-从零搭建

Mon, 15 Jan 2024 10:00:00 +0800

Version

7.4.1

创建空Web项目

dotnet new sln
dotnew new web --name AspNetCoreAbp
dotnet sln add .\AspNetCoreAbp

增加Abp的基础包

Volo.Abp.AspNetCore.Mvc

增加启动模块

考虑是使用WebApi模式，如下代码中就尽可能的精简，去除Mvc部分，Abp没有纯WebApi依赖模块，只有AbpAspNetCoreMvcModule模块。

using Volo.Abp;
using Volo.Abp.AspNetCore.Mvc;
using Volo.Abp.Modularity;


namespace AspNetCoreAbp;


[DependsOn(typeof(AbpAspNetCoreMvcModule))]
public class AspNetCoreAbpModule : AbpModule
{
    public override void OnApplicationInitialization(ApplicationInitializationContext context)
    {
        var app = context.GetApplicationBuilder();
        var env = context.GetEnvironment();


        app.UseRouting();
        app.UseConfiguredEndpoints();
    }
}

更改Program.cs

在7.0以上，ABP不用再单独弄一个Startup.cs文件，直接在Program.cs中启动模块就行。

默认代码

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();


app.MapGet("/", () => "Hello World!");


app.Run();

变更后代码

GenericRepository&UnitOfWork基本实现

Fri, 29 Dec 2023 10:00:00 +0800

前言

在DbContext中已经具备了事务，对于多个实体的操作，能够在一个事务中保证。借助仓储在基于DbContext上的封装，我们能够更好的扩展复用。泛型仓储的使用又能简化对于基础功能的依赖，但是当现有事务范围不足以覆盖或是多个仓储操作，多次调用SaveChange后，整体的事务范围便发生了变化，不能形成一个整体了。

事务范围

单次SaveChange

新增Order及OrderItem，两者本身都没问题的话，一次SaveChange可以全部成功。而当SaveChange完毕后，再出现异常(如下直接抛出异常test)，已有的事务已经提交完毕，无法回滚之前的操作了。

[HttpPost]
public async Task<int> CreateAsync(string name)
{
    var order = new Order()
    {
        Name = name,
        CreateDate = DateTime.UtcNow,
        OrderItems = new List<OrderItem>()
        {
            new OrderItem()
            {
                ProductId = 1,
                Amount = 1,
            }
        }
    };
    order = await _orderRepository.InsertAsync(order, autoSave: true);
    //throw new Exception("test");


    return order.Id;
}

多次SaveChange

类似于直接抛出事务，实现多次调用SaveChange，

第一次执行正常，执行SaveChange后数据入库，但在第二次操作时出现失败，第二次的入库操作能够回滚，但是第一次的SaveChange却是还是执行成功，从整个操作上，缺失了一致性。

public async Task<int> CreateMultiAsync(string name)
{
    var order = new Order()
    {
        Name = name,
        CreateDate = DateTime.UtcNow,
        OrderItems = new List<OrderItem>()
        {
            new OrderItem()
            {
                ProductId = 1,
                Amount = 1,
            }
        }
    };
    order = await _orderRepository.InsertAsync(order, autoSave: true);


    var orderError = new Order()
    {
        Name = name,
        CreateDate = DateTime.Now,//数据库中限制只允许utc
        OrderItems = new List<OrderItem>()
        {
            new OrderItem()
            {
                ProductId = 1,
                Amount = 1,
            }
        }
    };
    orderError = await _orderRepository.InsertAsync(orderError, autoSave: true);


    return order.Id;
}

这种场景在结合领域事件，在handler中还执行一些仓储操作时很容易出现，当没有一个全局的事务保证下，不可避免有这种风险。

GenericRepository

Wed, 29 Nov 2023 10:00:00 +0800

前言

自定义仓储能够很大程度方便我们实现功能，但是对于自定义仓储中的公共部分，又是非常基础的功能，如基础增删改和列表查询，分页查询，单个查询等，对于大部分自定义仓储来讲都能够用的上，如果每个自定义仓储中都实现一套，代码冗余度太高，无效工作过滤耗费时间。

构建泛型仓储

泛型仓储抽象接口

在自定义仓储接口基础上将常用的CRUD抽离出来到泛型仓储接口中，原有自定义变成泛型来代替，以使得自定义仓储接口集成泛型仓储接口后仍能够有基础常用功能。

对于自定义仓储的设计，如果实体能够映射到数据库表，那么便可为其增加仓储以便实现读写功能。因此，实体便是成为大多数自定义仓储命名规则，此处增加一个实体接口，一方面标时实体，另一方面约束泛型仓储，以只允许具有实体接口标时的实体才能使用泛型仓储。

public interface IEntity
{
}


public interface IEntity<TKey> : IEntity
{
    TKey Id { get; }
}

泛型仓储的设计上，参照ABP中泛型仓储，简化如下

public interface IRepository
{


}


public interface IRepository<TEntity, TKey> : IRepository
    where TEntity : class, IEntity<TKey>
{
    Task<TEntity> GetAsync(TKey id);
    Task<TEntity> GetAsync([NotNull] Expression<Func<TEntity, bool>> predicate);
    Task<TEntity> FindAsync(TKey id);
    Task<TEntity> FindAsync([NotNull] Expression<Func<TEntity, bool>> predicate);
    Task<List<TEntity>> GetListAsync();
    Task<List<TEntity>> GetListAsync([NotNull] Expression<Func<TEntity, bool>> predicate);
    Task<List<TEntity>> GetPagedListAsync(int skipCount, int maxResultCount, string sorting);
    Task<long> GetCountAsync();


    Task<TEntity> InsertAsync([NotNull] TEntity entity, bool autoSave = false);
    Task InsertManyAsync([NotNull] IEnumerable<TEntity> entities, bool autoSave = false);


    Task<TEntity> UpdateAsync([NotNull] TEntity entity, bool autoSave = false);
    Task UpdateManyAsync([NotNull] IEnumerable<TEntity> entities, bool autoSave = false);


    Task DeleteAsync(TKey id, bool autoSave = false);
    Task DeleteAsync([NotNull] TEntity entity, bool autoSave = false);
    Task DeleteAsync([NotNull] Expression<Func<TEntity, bool>> predicate, bool autoSave = false);
    Task DeleteManyAsync([NotNull] IEnumerable<TEntity> entities, bool autoSave = false);
    Task DeleteManyAsync([NotNull] IEnumerable<TKey> ids, bool autoSave = false);


 Task SaveChangesAsync();
    Task<IQueryable<TEntity>> WithDetailsAsync(params Expression<Func<TEntity, object>>[] propertySelectors);
    Task<IQueryable<TEntity>> GetQueryableAsync();
}

泛型仓储抽象实现

对于泛型仓储实现，先实现一个RepositoryBase，实现中并没有涉及到具体的技术实现，而是泛型仓储实现的抽象。与泛型仓储可属于同一层，都是领域层。

DbContext&Repository基本实现

Sun, 29 Oct 2023 10:00:00 +0800

前言

对于仓储模式，各有看法不同，直接使用DbContext简单方便，使用仓储模式扩展复用较好。受限于场景的差异，人员技能熟悉程度，交付时间，成本等选择哪种方式也有不同。

Controller&DbContext

当需要快速设计一个访问数据库Demo时，顺手便是Controller+DbContext，当然还有其他更为简便的方式，但是这套模式在使用频次上更高。

DbContext内部提供了常用的一些方法，直接操作DbContext很是方便，很自由，想怎么取怎么取，同时因为DbContext内部封装好了事务，因此多次变更一次提交之类的都很方便。

[ApiController]
[Route("[controller]")]
public class OrderController : ControllerBase
{
    private readonly AppDbContext _dbContext;


    public OrderController(AppDbContext dbContext)
    {
        _dbContext = dbContext;
    }


    [HttpGet("{id}")]
    public async Task<Order> GetAsync(int id)
    {
        return await _dbContext.Orders.AsNoTracking().FirstAsync(o => o.Id == id);
    }


    [HttpGet]
    public async Task<List<Order>> GetListAsync()
    {
        return await _dbContext.Orders.AsNoTracking().ToListAsync();
    }


    [HttpPost]
    public async Task<int> CreateAsync(string name)
    {
        var order = new Order()
        {
            Name = name,
            CreateDate = DateTime.UtcNow,
        };
        await _dbContext.Orders.AddAsync(order);
        await _dbContext.SaveChangesAsync();


        return order.Id;
    }


    [HttpPut("{id}")]
    public async Task<int> UpdateAsync(int id, string name)
    {
        var order = await _dbContext.Orders.FirstAsync(o=>o.Id == id);
        order.Name = name;
        await _dbContext.SaveChangesAsync();
        return order.Id;
    }


    [HttpDelete("{id}")]
    public async Task DeleteAsync(int id)
    {
        var order = await _dbContext.Orders.FirstAsync(o => o.Id == id);
        _dbContext.Orders.Remove(order);
        await _dbContext.SaveChangesAsync();
    }
}

可是使用方便的同时，有其他问题也需要考虑，如上代码如需要在其他Controller中查询，是不是又得写一遍，各种操作都得再来一遍，代码重复度很高。查询部分需要更加优化的查询性能等，受限EFCore的查询，需要更换到Dapper，那么纯查询操作的接口需要大面积改代码，相比下，引入仓储模式可能更加容易扩展，代码重用上也更佳。对于仓储模式结合DbContext，可以见到很多观点，有人认为多此一举，DbContext本身已经具备仓储功能及工作单元，没必要再在DbContext基础上再去封装。也有人认为需要封装，能够减少耦合，可扩展性更强。微软官方文档里也对此给了自己的看法，建议在复杂场景中使用仓储模式，以能更低成本的测试代码。

抽象CurrentUser适配Http和Job场景

Fri, 29 Sep 2023 10:00:00 +0800

前言

获取当前请求用户的基础信息是很常见的，诸如当前用户Id，角色，有无访问权限等。通常我们可以直接使用HttpContext.User来拿到当前经过认证后的请求人信息。但是这样对于分层应用不太友好，需要安装AspNetCore.Http.Abstractions的包，这样对于这层(非Web层)来讲也有所侵入了。

CurrentUser

很常用的一种方式是抽象与封装一层，比如ICurrentUser, ICurrentClient之类，具体实现放在Web层中以方便从HttpContext中获取用户或租户信息。而使用时，通过IOC在Domain中调用实例CurrentUser再获取详细信息。

代码示例

新建一个Asp.Net Core WebApi项目并增加一个Domain类库以添加ICurrentUser。

namespace CurrentUserDemo.Domain.CurrentUsers;


public interface ICurrentUser
{
    int? GetUserId();
    string? GetUserName();
}

在WebApi中实现CurrentUser，注入IHttpContextAccessor来获取当前用户信息。

using CurrentUserDemo.Api.Extensions;
using CurrentUserDemo.Domain.CurrentUsers;


namespace CurrentUserDemo.Api.Infrastructures.CurrentUsers;


public class CurrentUser : ICurrentUser
{
    private readonly IHttpContextAccessor _httpContextAccessor;


    public CurrentUser(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }


    public int? GetUserId()
    {
        return _httpContextAccessor.HttpContext?.User?.FindUserId();
    }


    public string? GetUserName()
    {
        return _httpContextAccessor.HttpContext?.User?.FindUserName();
    }
}

当Domain层想要获取用户信息时，注入ICurrentUser。

整合MediatR&Cap实现EventBus

Tue, 29 Aug 2023 10:00:00 +0800

在软件开发中，事件早已被我们所熟悉，一个按钮按下，产生中断事件，一个回车，前端页面有侦听事件，在事件风暴建模活动中，事件也是作为领域建模的突破口，事件的重要性不言而喻。其本质是发生的事实到引发了相关事情，在这其中的传递的信息便是事件的内容。就如同猫叫了，引发着老鼠跑了，主人醒了，其中的事件便是猫叫了，而该事件是猫执行叫的动作后的结果。

领域事件

在领域驱动设计中，最开始的版本中并没有领域事件的概念，在 DDD 社区对领域驱动设计的内容不断的充实中，引入了领域事件。领域事件的命名遵循英语中的“名词 + 动词过去分词”格式，如，提交订单后发布的 OrderCreated 事件，订单完成后 OrderCompleted 事件，用以表示我们建模的领域中发生过的一件事情，也符合着事件本身是具有时间特征。对于事件所通知到的范围的不同，领域事件本身也分为两类：

领域内事件，即领域事件，作用于进程内的通信。
领域间事件，即集成事件，作用于进程间的通信。

为实现事件的发布，可以借助一些现有的包集成到系统中，但又为了隔离使用上依赖了具体的技术实现，我们可以对其进行一定的封装。

MediatR

MediatR是.NET中的开源简单中介者模式实现，它通过一种进程内消息传递机制（无其他外部依赖），进行请求/响应、命令、查询、通知和事件的消息传递，并通过泛型来支持消息的智能调度。

https://github.com/jbogard/MediatR

Cap

CAP 本身就是一个EventBus，能处理进程内消息，同时也是一个在微服务或者SOA系统中解决分布式事务问题的一个框架。它有助于创建可扩展，可靠并且易于更改的微服务系统。

https://github.com/dotnetcore/CAP

抽象EventBus

新建EventBus.Abstractions类库，用来抽象领域事件和集成事件的发布。

dotnet new classlib --name EventBusDemo.EventBus.Abstractions

在MediatR中，有一个抽象的Contracts类库，方便我们构建一个抽象的EventBus。 MediatR发布事件时，事件类上必须要有标记，比如如下INotification标记，因此，此处增加领域事件接口约束，来隔离INotification。

using MediatR;


namespace EventBusDemo.EventBus.Abstractions.Local;


public interface IDomainEvent : INotification
{
}

本地事件EventBus, 参照MediatR中已有接口，替换约束类。

namespace EventBusDemo.EventBus.Abstractions.Local;


public interface ILocalEventBUs
{
    Task Publish(IDomainEvent domainEvent, CancellationToken cancellationToken = default);


    Task Publish<T>(T domainEvent, CancellationToken cancellationToken = default)
        where T : IDomainEvent;
}

同样，增加集成事件，Cap框架没有限制集成事件类的约束条件，而为了能够统一标识项目中的集成事件，还是有必要设置一个接口约束。

DotNetCore&Channels

Sun, 23 Jul 2023 10:00:00 +0800

https://www.cnblogs.com/CKExp/p/17575349.html

前言

生活中可以见到很多传送带，河道，工厂流水线，快递服务等。去站点寄个快递，通过传送带，将快递从一端传递到另一端，再去站点收个快递。参照这种设计，我们可以将其融入到软件中，以实现许多功能。

在.Net Core中实现了一个高效，线程安全的队列System.Threading.Channels，与RabbitMQ、Kafka这种跨进程的消息队列，使用场景上不同，Channels在进程内跨线程使用。从使用方式上，Channels也更简单，不需要额外引入包(.Net Core3.0后)。

Channels

Channel其本质上是一个高效的、线程安全的队列，支持在生产者和消费者之间存储和传递数据。一端(生产者)负责将数据写入Channel，另一端(消费者)可以从Channel中读取数据并进行处理。

https://devblogs.microsoft.com/dotnet/an-introduction-to-system-threading-channels/

Channel机制下一个消息只能由一个消费者来消费。

Channel的两种模式

Bounded Channels: 有限存储空间的Channel，对传入消息的容量有限，限定生产者在满足空间数量之前只能发布特定的次数。超过了则需要等待(非阻塞等待)消费者消费减少空间内消息数量后再继续发布。
Unbounded Channels: 无限存储空间的Channel，生产者可以一直发布，但如果消费者的消费跟不上节奏，那么资源则会不断增大，有可能耗尽服务器资源。两者都是通过Channel提供的工厂方法来创建。

public static class Channel
{
 public static Channel<T> CreateBounded(int capacity);
 public static Channel<T> CreateBounded(BoundedChannelOptions options);
 public static Channel<T> CreateUnbounded();
 public static Channel<T> CreateUnbounded(UnboundedChannelOptions options);
}

对于不同的模式会有不同的实现类。

public abstract class Channel<TWrite, TRead>
{
 public ChannelReader<TRead> Reader { get; protected set; } = null!;
 public ChannelWriter<TWrite> Writer { get; protected set; } = null!;
}


public abstract class Channel<T> : Channel<T, T> { }


public class BoundedChannel<T> : Channel<T> { }


public class UnboundedChannel<T> : Channel<T> { }

写入到Channel

生产者可以通过ChannelWrite来将消息写入到Channel中。

DotNet472&6.0在Razor编译时的小差异

Wed, 28 Jun 2023 10:00:00 +0800

前言

几个月前在进行着.Net 472到6.0的升级，复用原有代码，在对Razor进行迁移中，发现原运行正常的代码，却存在报错，深入研究发现是Core下对Razor编译有一些变动。

问题复现

472 创建视图

新建.Net Framework下Mvc，增加一个简单视图如下。

@{
 Layout = null;
}
<!DOCTYPE html>
<html lang="en">
<head>
 <meta charset="utf-8" />
 <meta name="viewport" content="width=device-width, initial-scale=1.0" />
 <title>@ViewData["Title"] - RazorDemo472.Web</title>
 @{
 var headContent = "headContent";
 }
</head>
<body>
 <h1>@headContent</h1>
</body>
</html>

暂不论这个变量定义的位置合不合适，或许应该全局定义，但是总归在472下是正常的，可运行的。

6.0 创建视图

新建Asp.Net Core Mvc项目，同样使用如上简单视图

@{
 Layout = null;
}
<!DOCTYPE html>
<html lang="en">
<head>
 <meta charset="utf-8" />
 <meta name="viewport" content="width=device-width, initial-scale=1.0" />
 <title>@ViewData["Title"] - RazorDemo6.Web</title>
 @{
 var headContent = "headContent";
 }
</head>
<body>
 <h1>@headContent</h1>
</body>
</html>

如果只是这样，不做任何设置，编译时候就会报错。

通过Serverless私有化部署ChatGPT-Web

Thu, 11 May 2023 10:00:00 +0800

作为开发人员，想要自己部署一个渠道访问或是想随时访问但是奈何魔法有限，又或是海外服务器太贵，不想耗费这个钱，本文借助 Serverless 来搭建一下私有 ChatGPT 服务，Serverless 按照使用量来计费，个人使用下(满足工作和生活)费用相当低。

本文过程较为繁琐，也有更为简便的其他方式：

https://rptzik3toh.feishu.cn/docx/XtrdduHwXoSCGIxeFLlcEPsdn8b

前言

本次搭建过程需要满足以下几个条件，需要预先满足，已经注册或是从一些渠道获取到了 Api key，有自己的备案域名。

已有 Api key
需要开通阿里云 Serverless
需要开通阿里云容器镜像服务
已有备案域名

云函数

开通服务(略过,免费开通)， https://www.aliyun.com/product/fc

顶部选择地域，如硅谷
左侧选择服务及函数
创建服务，填写服务描述信息即可

容器镜像服务

开通服务(掠过，免费开通)， https://www.aliyun.com/product/acr

顶部选择海外站点，如硅谷

进入个人实例。创建镜像仓库，下一步中选择本地仓库，保存。

点击仓库名称进入仓库内部，该部分命令稍后会用到，此处只需看到即可。

ChatGPTVNextWeb

https://github.com/Yidadaa/ChatGPT-Next-Web

该仓库实现了 ChatGPT 的交互 UI，提供了 Docker 镜像方便部署。可将该镜像上传到个人的容器镜像服务(供 Serverless 绑定部署使用)。

拉取 VNextWeb 镜像到本地

docker pull yidadaa/chatgpt-next-web

本地登录容器镜像服务(见容器镜像服务节末图)

docker login --username=用户名 registry.us-west-1.aliyuncs.com

标记本地 VNextWeb 镜像版本

查看镜像 id

docker images

eg：查看本地镜像，复制Id

设置镜像版本

docker tag [ImageId] registry.us-west-1.aliyuncs.com/partner/chatgptnextweb:[镜像版本号]

eg：此处直接标记最新版本 latest

DotNetCore Console&Cache

Sun, 30 Apr 2023 10:00:00 +0800

前言

有时候想快速验证一些想法，新建一个控制台来弄，可控制台模板是轻量级的应用程序模板，不具备配置、日志、依赖注入等一些功能。

缓存

在网站开发中，缓存无处不在，它能够极大地提高硬件和软件的运行速度。性能优化的第一步便是使用缓存，例如频繁的从数据库中读取，需要和底层IO交互，性能受限，如将常用数据加载到内存中，那么便可以极大的提升性能。

Nuget包

缓存抽象包

Install-Package Microsoft.Extensions.Caching.Abstractions

如使用内存做缓存

Install-Package Microsoft.Extensions.Caching.Memory

如使用Redis做缓存

Install-Package Microsoft.Extensions.Caching.Redis

还有其他一些缓存包，此处省略

缓存使用

新建控制台项目，此处使用Memory包，简单存取一个字符串到内存中。

using Microsoft.Extensions.Caching.Memory;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;


var host = Host.CreateDefaultBuilder(args)
    .ConfigureServices((hostContext, services) =>
    {
        services.AddMemoryCache();
    })
    .Build();


using (var serviceScope = host.Services.CreateScope())
{
    var services = serviceScope.ServiceProvider;
    var cache = services.GetRequiredService<IMemoryCache>();
    cache.Set("key", "value");


    Console.WriteLine(cache.Get("key"));
}

如上使用了通用主机包 Microsoft.Extensions.Hosting

DotNetCore Console&GenericHostBuilder

Sat, 08 Apr 2023 10:00:00 +0800

前言

有时候想快速验证一些想法，新建一个控制台来弄，可控制台模板是轻量级的应用程序模板，不具备配置、日志、依赖注入等一些功能。

通用主机

在Asp.Net Core中有WebHostBuilder来提供DI，Configuratio，日志等功能，很是齐全，如果是在控制台中使用呢，或是使用的场景不单单是Web呢，比如测试项目，独立Job，桌面应用等，除了手动一个一个搭建外，也可以使用Generic HostBuilder，类似于WebHostBuilder，也提供了基础的功能，免于我们再去基建。

https://source.dot.net/#Microsoft.Extensions.Hosting/HostBuilder.cs,148

Generic HostBuilder是在.Net Core2.1时候提出的并被设计成能够在非Http模式和Http模式下都可以用。

安装Nuget包

Install-Package Microsoft.Extensions.Hosting

构建主机

开始使用Generic HostBuilder，可以手动实例化HostBuilder，

var hostBuilder = new HostBuilder();

或是调用Host中的扩展方法来完成创建。

var hostBuilder = Host.CreateDefaultBuilder(args)

实际上，扩展方法中是在手动实例化的基础上包装并做好了一些基础配置与服务注册，源码位置： https://source.dot.net/#Microsoft.Extensions.Hosting/Host.cs,53

微软官网文档中也提及了CreateDefaultBuilder中完成的一些事情。

https://learn.microsoft.com/en-us/dotnet/core/extensions/generic-host#default-builder-settings

服务注册

Generic HostBuilder很是方便我们去使用DI，在HostBuilder尚未执行Build方法前，先注册一些服务到容器中，此处注册个简单服务。

以订单服务类作为示例，增加接口类与实现类。

public interface IOrderService
{
    void AutoCancel();
}


public class OrderService : IOrderService
{
    private readonly ILogger<OrderService> _logger;


    public OrderService(ILogger<OrderService> logger)
    {
        _logger = logger;
    }


    public void AutoCancel()
    {
        _logger.LogInformation("Start AutoCancel");
        Console.WriteLine("Order canceled!");
        _logger.LogInformation("Finished AutoCancel");
    }
}

注册到服务容器中，此处使用瞬时的生命周期。

DotNetCore Console&Logger

Wed, 15 Mar 2023 10:00:00 +0800

前言

有时候想快速验证一些想法，新建一个控制台来弄，可控制台模板是轻量级的应用程序模板，不具备配置、日志、依赖注入等一些功能。

日志

.Net Core自带了一个基础的logger框架Microsoft.Extensions.Logging提供记录日志功能，能够按日志不同级别记录日志信息(Information, Warning, Error等)。

LogLevel	值	扩展方法	描述
Trace	0	LogTrace	追踪：包含最详细的信息。可能包含机密信息。预设为停用，且不应该在生产环境中启用。
Debug	1	LogDebug	调试：开发调试并在调试工具中展示。生产环境中小心使用，日志条数庞大。
Information	2	LogInformation	信息：跟踪程序执行的一般流程。可能具有长期值。
Warning	3	LogWarning	警告：针对异常或或非预期的事件。通常包含不会导致应用失败的错误或状况。
Error	4	LogError	错误：发生无法处理的错误或异常。这些记录表示目前的执行流程或任务失败，但不是整个程序失败。
Critical	5	LogCritical	严重：发生需要立即关注的失败。例如：磁盘空间不足。
None	6		指定记录类别不应写入任何信息。

.Net Core中使用ILogger来记录日志，可以在不同模板应用上使用，如控制台应用，Asp.Net Core，WPF等，Asp.Net Core里使用十分简单，可以直接通过DI注册与获取到ILogger，但在控制台模式中，需要我们自己去配置。

安装Nuget包

新建控制台项目并安装Logger的包，此处使用日志输出渠道为Console中直接展示

Install-Package Microsoft.Extensions.Logging.Console

Logging基础包(Microsoft.Extensions.Logging)在Console已有依赖,此处不再额外安装。同时，Logging基础包中依赖了DI的基础包，使用上极其方便了。

服务注册

将日志服务加入到服务容器中，此处设置Console作为日志输出渠道，还可以设置其他渠道。

https://source.dot.net/#Microsoft.Extensions.Logging/LoggingServiceCollectionExtensions.cs

额外注册了一个OrderJob，用来在OrderJob中输出日志，构建ServiceProvider获取容器提供的服务实例。

var services = new ServiceCollection();
services.AddLogging(configure => configure.AddConsole());
services.AddTransient<OrderJob>();
using (ServiceProvider serviceProvider = services.BuildServiceProvider())
{
    var orderJob = serviceProvider.GetService<OrderJob>()!;
    orderJob.Execute();
}

在OrderJob中通过构造函数注入使用Logger，也可以注入ILoggerFactory创建Logger

DotNetCore Console&DependencyInjection

Sun, 05 Mar 2023 10:00:00 +0800

前言

有时候想快速验证一些想法，新建一个控制台来弄，可控制台模板是轻量级的应用程序模板，不具备配置、日志、依赖注入等一些功能。

依赖注入

在Asp.Net Core应用程序中，可以通过依赖注入使用IConfiguration接口来使用配置。而控制台模板十分简单，没有内置依赖注入，应用程序所依赖的功能(如配置)不容易获得。使用IOC(控制反转)容器实现依赖注入简要步骤

创建Service Collection。
将服务注册到Service Collection。
Service Collection构建Service Provider。
使用Service Provider获取服务

安装Nuget包

Install-Package Microsoft.Extensions.DependencyInjection

创建服务容器

需要准备一个Service Collection(服务容器)，用来存储服务的注册与从其中获取服务。微软已提供了ServiceCollection类。

https://source.dot.net/#Microsoft.Extensions.DependencyInjection.Abstractions/ServiceCollection.cs,4219db14266c9d57

在Asp.Net Core 源码中，Service Collection在WebHostBuilder中实例化好了。

https://source.dot.net/#Microsoft.AspNetCore.Hosting/WebHostBuilder.cs,c278c6966995108c

BuildCommonServices方法中，完成Service Collection实例化与应用需要的服务注册。

在控制台模板中，需要自己去创建实例。

var services = new ServiceCollection();

服务注册

服务注册到服务容器中时需要指明服务本身的生命周期，有三种设置，全局单例(Singleton)，请求内单例(Scope)，瞬时(Transient)。以订单服务类作为示例，增加接口类与实现类。

public interface IOrderService
{
    void AutoCancel();
}


public class OrderService : IOrderService
{
    public void AutoCancel()
    {
        Console.WriteLine("Order canceled!");
    }
}

注册到服务容器中，此处使用瞬时的生命周期。

services.AddTransient<IOrderService, OrderService>();

构建服务提供者

通过服务容器转换得到服务提供者，使用已有扩展方法

DotNetCore Console&Configuration

Mon, 27 Feb 2023 10:00:00 +0800

前言

有时候想快速验证一些想法，新建一个控制台来弄，可控制台模板是轻量级的应用程序模板，不具备配置、日志、依赖注入等一些功能。

Configuration

在Asp.Net Core应用程序中，可以通过依赖注入使用IConfiguration接口来使用配置。而控制台模板十分简单，没有内置依赖注入，应用程序所依赖的功能(如配置)不容易获得。因此需要一点点在控制台中搭建最为基本的功能，想要使用配置，可通过ConfigurationBuilder类来创建Configuration，还可以使用Json文件、机密文件、环境变量、命令行或自定义的配置提供程序来作为配置源获取配置信息。

安装Configuration包

安装相关NuGet包，每个包的用途看名字就很一目了然。

Install-Package Microsoft.Extensions.Configuration
Install-Package Microsoft.Extensions.Configuration.Json
Install-Package Microsoft.Extensions.Configuration.CommandLine
Install-Package Microsoft.Extensions.Configuration.UserSecrets
Install-Package Microsoft.Extensions.Configuration.EnvironmentVariables

组装Configuration

如下代码中，添加了一个appsetings.json的配置文件并设置其属性复制到项目输出文件夹，还添加了环境变量、用户机密和命令行作为配置源。最后构建Configuration。

using Microsoft.Extensions.Configuration;


IConfiguration Configuration = new ConfigurationBuilder()
 .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
 .AddUserSecrets<Program>()
 .AddEnvironmentVariables()
 .AddCommandLine(args)
 .Build();

如上配置源会由后者优先级最高覆盖前者相同配置。

使用Configuration

已经构建了配置提供程序，可以按照下面的方式使用它们

// 获取配置节
var section = Configuration.GetSection("ConnectionStrings");


// 获取值
var value = Configuration.GetValue("ConnectionStrings:Default");

强类型对象

配置节可以映射到强类型对象(选项模式)，安装如下Nuget包，可以使用Bind 方法将配置节映射到强类型对象，又或是使用Get方法(推荐)同样的作用。

Install-Package Microsoft.Extensions.Configuration.Binder

例如，有下面的类表示Jwt配置

public class JwtOptions
{
 public const string Name = "Jwt";


 public string Audience { get; set; }
 public string Issuer { get; set; }
 public double ExpiresMinutes { get; set; } = 30d;
 public string SymmetricSecurityKeyString { get; set; }
}

Json配置文件中加入配置节点

Prometheus&Alertmanager告警推送

Thu, 23 Feb 2023 10:00:00 +0800

前言

尽管可以通过可视化数据监控系统运行状态，但我们无法时刻关注系统运行，因此需要一些实时运行的工具能够辅助监控系统运行，当系统出现运行问题时，能够通知我们，以此确保系统稳定性，告警便是作为度量指标监控中及其重要的一环。

Prometheus告警介绍

在Prometheus中，告警模块为Alertmanager，可以提供多种告警通道、方式来使得系统出现问题可以推送告警消息给相关人员。

Prometheus Server中的告警规则会向Alertmanager发送。Alertmanager管理这些告警，包括进行去重，分组和路由，以及告警的静默和抑制，通过电子邮件、实时通知系统和聊天平台等方法发送通知。

定义告警规则(Alerting rule)
告警模块消息推送(Alertmanager)
告警推送(Prometheus server推送告警规则到Alertmanager)

Alertmanager

Alertmanager是一个独立的告警模块，接收Prometheus server发来的告警规则，通过去重、分组、静默和抑制等处理，并将它们通过路由发送给正确的接收器。

核心概念

分组(Grouping): 是Alertmanager把同类型的告警进行分组，合并多条告警合并成一个通知。当系统中许多实例出问题时又或是网络延迟、延迟导致网络抖动等问题导致链接故障，会引发大量告警，在这种情况下使用分组机制，把这些被触发的告警合并为一个告警进行通知，从而避免瞬间突发性的接受大量告警通知，使得相关人员可以对问题快速定位，而不至于淹没在告警中。
抑制(Inhibition): 是当某条告警已经发送，停止重复发送由此告警引发的其他异常或故障的告警机制，以避免收到过多无用的告警通知。
静默(Silences): 可对告警进行静默处理的简单机制。对传进来的告警进行匹配检查，如果告警符合静默的配置，Alertmanager 则不会发送告警通知。

设置Alertmanager.yml

cd /opt
mkdir alertmanager
cd alertmanager
touch alertmanager.yml

配置文件主要包含以下几个部分：

全局配置（global）：用于定义一些全局的公共参数，如全局的SMTP配置，Slack配置等内容；
模板（templates）：用于定义告警通知时的模板，如HTML模板，邮件模板，企业微信模板等；
告警路由（route）：根据标签匹配，确定当前告警应该如何处理；
接收人（receivers）：接收人是一个抽象的概念，它可以是一个邮箱也可以是微信，Slack或者Webhook等，接收人一般配合告警路由使用；

配置文件内容：

global:
 resolve_timeout: 2m
 smtp_smarthost: 'smtp.qq.com:465'
 smtp_from: your@qq.com
 smtp_auth_username: your@qq.com
 smtp_auth_password: 授权码
templates:
 - /etc/alertmanager/template/*.tmpl
route:
 group_by:
 - alertname_wechat
 group_wait: 10s
 group_interval: 10s
 receiver: wechat
 repeat_interval: 1h
receivers:
 - name: wechat
 email_configs:
 - to: otheremail@outlook.com
 send_resolved: true
 wechat_configs:
 - corp_id: wechat_corp_id
 to_party: wechat_to_party
 agent_id: wechat_agent_id
 api_secret: wechat_apisecret
 send_resolved: true

此处设置推送消息到邮箱和企业微信，Alertmanager内置了对企业微信的支持。 https://prometheus.io/docs/alerting/latest/configuration/#wechat_config

Prometheus&Grafana基本使用

Tue, 31 Jan 2023 10:00:00 +0800

Prometheus介绍

Prometheus 是一套开源的系统监控与报警框架，以便于我们能够监控生产环境下的应用与服务。启发于 Google 的 BorgMon 监控系统，由工作在 SoundCloud 的 google 前员工在 2012 年创建，作为社区开源项目进行开发，并于 2015 年正式发布。2016 年，Prometheus 正式加入CNCF(Cloud Native Computing Foundation)，成为受欢迎度仅次于 Kubernetes 的项目。

Prometheus特点

作为新一代的监控框架，Prometheus 具有以下特点：

多维度数据模型：
- 时间序列数据通过 metric 名和键值对来区分。
- 所有的 metrics 都可以设置任意的多维标签。
- 数据模型更随意，不需要刻意设置为以点分隔的字符串。
- 可以对数据模型进行聚合，切割和切片操作。
- 支持双精度浮点类型，标签可以设为全 unicode。
灵活而强大的查询语句（PromQL）：在同一个查询语句，可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。
易于管理： Prometheus server 是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储。
高效：平均每个采样点仅占 3.5 bytes，且一个 Prometheus server 可以处理数百万的 metrics。
使用 pull 模式采集时序数据，这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics。
可以采用 push gateway 的方式把时序数据推送至 Prometheus server 端。
可以通过服务发现或者静态配置去获取监控的 targets。
支持多种可视化图形界面，比如Grafana等。

Prometheus组件

Prometheus server

主要负责数据采集和存储，提供PromQL查询语言的支持。包含了三个组件：

Retrieval: 获取监控数据

AspNetCore&Cookie认证授权

Sun, 15 Jan 2023 10:00:00 +0800

有时想快速搭建一个简单Demo或是需要验证授权完成后的一些动作，总是需要去找一番，有时还要不断去翻找到适合的，或是copy过来又不能使用又或是过时的。

认证与授权说来说去还是四个核心步骤

登录(SignIn)，为了获得当前请求人是谁的标识
退出(SignOut)，令系统移除请求人的标识
请求资源时识别请求人是谁(Authentication)
判断对资源请求的权限(Authorization)
- 有身份信息但没有权限后拒绝操作(Challenge)
- 没有身份信息则说未授权(Forbid)
- 有身份信息且有权限则访问资源

Cookie 是用来在客户端存储会话信息的，它要求服务器在响应给客户端信息时，携带一个头部字段 Set-Cookie，其内容为键值对，保存一些需要存储在客户端本地的信息。在之后的每一次请求中，浏览器会将这些信息，携带在请求头部字段 Cookie 中，发送给服务器，用以标识客户端的身份。

快速实践

项目准备

准备一个Asp.Net Core 6.0的Web(前端简单展示)。按照如上几个用例挨个实现(退出用例不考虑)

增加Account控制器

简单实现，跳过账号验证之类的过程，主要是生成一个Cookie，方便请求其他需要授权验证的接口

public class AccountController : Controller
{
    public async Task<IActionResult> GenerateCookie(string userName = "9527")
    {
        var claims = new List<Claim>()
        {
            new Claim("id", "1"),
            new Claim(ClaimTypes.Name,userName),
            new Claim(ClaimTypes.Role,"Admin"),
        };
        var claimsIdentity = new ClaimsIdentity(claims, "Custom");
        var claimsPrincipal = new ClaimsPrincipal(claimsIdentity);


        await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, claimsPrincipal, new AuthenticationProperties
        {
            ExpiresUtc = DateTime.Now.AddMinutes(30)
        });


        return Content(HttpContext.Response.Headers.SetCookie);
    }
}

服务注册

using Microsoft.AspNetCore.Authentication.Cookies;


var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();//包含Authorize需要的服务
builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie();//使用Cookie作为鉴权Schema


var app = builder.Build();
app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthentication();//使用鉴权中间件
app.UseAuthorization();
app.MapDefaultControllerRoute();
app.Run();

获取Cookie

简单点，直接Postman请求拿到Cookie，然后便方便对其他接口测试。

Jaeger&ElasticSearch存储链路追踪数据

Mon, 26 Dec 2022 10:00:00 +0800

前言

Jaeger的all in one镜像下是用内存存储(或是临时文件格式存储)，容器重启，数据丢失。生产环境下更多是存储到es或是cassandra，这样对于查询或是系统扩展是比较方便的。此处介绍Jaeger的几个组件独立部署以及存储到ElasticSearch中。使用单个拉取镜像创建容器的方式，不通过docker compose批量创建。

Jaeger

组件部分

all in one镜像中，如下几个部分全部打包到一个镜像中。此处对这几个部分使用各组件独立镜像单独部署。

Jaeger Agent: 一个监听在UDP端口上接收链路数据的网络守护进程，它从应用程序收集，批处理，并发送给Collector，(也可以没有这个，client直接上报)。
Jaeger Collector: 负责接收Jaeger-client或Jaeger-agent上报的调用链路数据，并通过处理管道运行它们，该管道验证跟踪、对它们进行索引、执行任何转换并最终保存到内存或外部存储系统中，供UI展示。
Jaeger Query: 查询服务从存储中检索跟踪并呈现 UI 来显示它们。
DB: 采用EleasticSearch作为存储引擎。
Jaeger Spark dependencies: 从存储中收集span数据，分析服务间的连接和依赖，并将它们存储起来以便在Jaeger UI 中显示。all in one镜像中不需要这个。

组件镜像

官网提供了镜像的拉取命令，版本，用途等信息。

https://www.jaegertracing.io/download/

Jaeger Collector

拉取镜像

docker pull jaegertracing/jaeger-collector:1.40

创建容器

docker run -d --name=StarCityJaegerCollector -p 9411:9411 -p 14250:14250 -p 14268:14268 -e SPAN_STORAGE_TYPE=elasticsearch -e ES_SERVER_URLS=http://es ip:9200 jaegertracing/jaeger-collector:1.40

端口说明

端口号	协议	功能
9411	HTTP	能通过 JSON 或 Thrift 接收 Zipkin spans，默认关闭
14250	gRPC	用于jaeger-agent发送model格式的span
14268	HTTP	能直接接收来自客户端的 jaeger.thrift 格式的 span
14269	HTTP	健康检查与自身服务的度量指标

Jaeger Agent

拉取镜像

docker pull jaegertracing/jaeger-agent:1.40

创建容器

docker run -d --name=StarCityJaegerAgent -p 6831:6831/udp -p 6832:6832/udp -p 5778:5778/tcp -p 5775:5775/udp -e REPORTER_GRPC_HOST_PORT=Jaeger Collecor Ip:14250 -e LOG_LEVEL=debug jaegertracing/jaeger-agent:1.40

其中REPORTER_GRPC_HOST_PORT即为Agent要上报到Collector的地址

AspNet Core&Jaeger实现链路追踪

Mon, 28 Nov 2022 10:00:00 +0800

前言

随着应用愈发复杂，请求的链路也愈发复杂，微服务化下，更是使得不同的服务分布在不同的机器，地域，语言也不尽相同。因此需要借助工具帮助分析，跟踪，定位请求中出现的若干问题，以此来保障服务治理，链路追踪也就出现了。

OpenTracing协议

OpenTracing是一套分布式追踪协议，与平台，语言、厂商无关的Trace协议，统一接口，使得开发人员能够方便的添加或更换更换不同的分布式追踪系统。

语义规范 : 描述定义的数据模型 Tracer，Sapn 和 SpanContext 等；
语义惯例 : 罗列出 tag 和 logging 操作时，标准的key值；

同样作为分布式追踪协议的还有OpenCensus，以及两者的合并体OpenTelemetry。

Jaeger介绍

Jaeger[ˈdʒɛgər]是Uber推出的一款开源分布式追踪系统，兼容OpenTracing API，已在Uber大规模使用，且已加入CNCF开源组织(Cloud Native Computing Foundation-云原生计算基金会)。其主要功能是聚合来自各个异构系统的实时监控数据。

Jager提供了一套完整的追踪系统包括Jaeger-client、Jaeger-agent、Jaeger-collector、Database和Jaeger-query UI等基本组件。

Jaeger-client：为不同开发语言实现了符合OpenTracing协议的客户端。
Jaeger-agent：一个监听在UDP端口上接收链路数据的网络守护进程，它从应用程序收集，批处理，并发送给Collector，(也可以没有这个，client直接上报)。
Jaeger-collector：负责接收Jaeger-client或Jaeger-agent上报的调用链路数据，并通过处理管道运行它们，该管道验证跟踪、对它们进行索引、执行任何转换并最终保存到内存或外部存储系统中，供UI展示。
Jaeger-query：查询服务从存储中检索跟踪并呈现 UI 来显示它们。

Jaeger安装

在个人使用或者测试上，Jaeger提供了jaegertracing/all-in-one镜像，搭建过程十分简单，数据存储在内存中，但需要注意容器挂了后数据就没了。

docker run -d -p 6831:6831/udp -p 16686:16686 jaegertracing/all-in-one:latest

创建容器运行后，可以访问ip:16686查看Jaeger的仪表面板

Jaeger应用

服务设计

简化大部分服务设计，整个结构上差不多是如下所示，服务层常见金字塔结构，服务上下游明确，以避免服务间的循环依赖。

此处建立四个服务以及一个BFF网关层，以满足服务同步调用，服务间上下游调用，以及服务间事件通信。

JaegerDemo.BFF.Host
JaegerDemo.AService.Host
JaegerDemo.BService.Host
JaegerDemo.CService.Host
JaegerDemo.DService.Host

为这几个服务设定期望如下

执行Get请求时，从Gateway调用，请求A服务，在同步请求B和C服务，拿到结果组装后对外返回。
执行Post请求时，从Gateway调用，请求A服务，在发布事件到MQ中，D服务订阅事件，数据写入到Sqlite中。

Nuget包引用

Jaeger，用来上传数据到Jaeger。
OpenTracing.Contrib.NetCore，基于OpenTracing.Net的增强，用来采集应用数据。
MassTransit和MassTransit.RabbitMQ，用来完成事件的发布订阅。

<ItemGroup>
  <PackageReference Include="OpenTracing" Version="0.12.1" />
  <PackageReference Include="Jaeger" Version="1.0.3" />
  <PackageReference Include="MassTransit" Version="8.0.8" />
  <PackageReference Include="MassTransit.RabbitMQ" Version="8.0.8" />
</ItemGroup>

服务注册

将服务注册到容器中，设置上报地址，注意此处上报地址是UDP类型，因此在云服务器中开安全组时需要是UDP类型

DotNet Core&RabbitMQ限制循环消费

Sat, 29 Oct 2022 10:00:00 +0800

前言

当消费者端接收消息处理业务时，如果出现异常或是拒收消息将消息又变更为等待投递再次推送给消费者，这样一来，则形成循环的条件。

循环场景

生产者发送100条消息到RabbitMQ中，消费者设定读取到第50条消息时，设置拒收，同时设定是否还留存在当前队列中(当requeue为false时，设置了死信队列则进入死信队列，否则移除消息)。

consumer.Received += (model, ea) =>
{
    var message = ea.Body;
    Console.WriteLine("接收到信息为:" + Encoding.UTF8.GetString(message.ToArray()));


    if (Encoding.UTF8.GetString(message.ToArray()).Contains("50"))
    {
        Console.WriteLine("拒收");
        ((EventingBasicConsumer)model).Model.BasicReject(ea.DeliveryTag, requeue: true);
        return;
    }


    ((EventingBasicConsumer)model).Model.BasicAck(ea.DeliveryTag, multiple: false);
};

当第50条消息拒收，则仍在队列中且处在队列头部，重新推送给消费者，再次拒收，再次推送，反反复复。最终其他消息全部消费完毕，仅剩第50条消息往复间不断消费，拒收，消费，这将可能导致RabbitMQ出现内存泄漏问题。

解决方案

RabbitMQ及AMQP协议本身没有提供这类重试功能，但可以利用一些已有的功能来间接实现重试限定(以下只考虑基于手动确认模式情况)。此处只想到或是只查到了如下几种方案解决消息循环消费问题。

一次消费
- 无论成功与否，消费者都对外返回ack，将拒收原因或是异常信息catch存入本地或是新队列中另作重试。
- 消费者拒绝消息或是出现异常，返回Nack或Reject，消息进入死信队列或丢弃(requeue设定为false)。
限定重试次数
- 在消息的头中添加重试次数，并将消息重新发送出去，再每次重新消费时从头中判断重试次数，递增或递减该值，直到达到限制，requeue改为false，最终进入死信队列或丢弃。
- 可以在Redis、Memcache或其他存储中存储消息唯一键（例如Guid、雪花Id等，但必须在发布消息时手动设置它），甚至在mysql中连同重试次数一起存储，然后在每次重新消费时递增/递减该值，直到达到限制，requeue改为false，最终进入死信队列或丢弃。
- 队列使用Quorum类型，限制投递次数，超过次数消息被删除。
队列消息过期
- 设置过期时间，给队列或是消息设置TTL，重试一定次数消息达到过期时间后进入死信队列或丢弃(requeue设定为true)。
也许还有更多好的方案…

一次消费

对外总是Ack

消息到达了消费端，可因某些原因消费失败了，对外可以发送Ack，而在内部走额外的方式去执行补偿操作，比如将消息转发到内部的RabbitMQ或是其他处理方式，终归是只消费一次。

var queueName = "alwaysack_queue";
channel.QueueDeclare(queue: queueName, durable: false, exclusive: false, autoDelete: false, arguments: null);
channel.BasicQos(0, 5, false);


var consumer = new EventingBasicConsumer(channel);
consumer.Received += (model, ea) =>
{
    try
    {
        var message = ea.Body;
        Console.WriteLine("接收到信息为:" + Encoding.UTF8.GetString(message.ToArray()));


        if (Encoding.UTF8.GetString(message.ToArray()).Contains("50"))
        {
            throw new Exception("模拟异常");
        }
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
    finally
    {
        ((EventingBasicConsumer)model).Model.BasicAck(ea.DeliveryTag, multiple: false);
    }
};


channel.BasicConsume(queue: queueName, autoAck: false, consumer: consumer);

当消费端收到消息，处理时出现异常，可以另想办法去处理，而对外保持着ack的返回，以避免消息的循环消费。

DotNet Core&RabbitMQ优先级队列

Mon, 05 Sep 2022 10:00:00 +0800

优先级队列

消息除了有生命周期长短，也有紧急与非紧急之分，承载了具有优先级消息的队列则为优先级队列。

队列优先级设置

为消息设置优先级前，队列需要先具备优先级的能力，队列设置参数时，可添加x-max-priority来设置队列中消息能够达到的最高优先级(255封顶但推荐设置在1-10之间)。

var queueName = "priority_queue";
var arguments = new Dictionary<string, object>
{
    { "x-max-priority", 3 }
};
channel.QueueDeclare(queue: queueName, durable: false, exclusive: false, autoDelete: false, arguments: arguments);

Web管理页面中可以看到该队列打上了Pri的Tag。

消息优先级设置

为消息设置优先级，以此在队列中消息很多时，优先级高的消息可以被优先消费。发送消息时添加参数，设置Priority属性。

for (int i = 0; i < 10; i++)
{
    var message = "第" + (i + 1) + "条消息";
    byte priority = 0;
    switch (i)
    {
        case < 3:
            message += "-info";
            priority = 1;
            break;
        case < 6:
            message += "-warn";
            priority = 2;
            break;
        default:
            message += "-error";
            priority = 3;
            break;
    }


    var body = Encoding.UTF8.GetBytes(message);
    var basicProperties = channel.CreateBasicProperties();
    basicProperties.Priority = priority;
    channel.BasicPublish(exchange: "", routingKey: queueName, basicProperties: basicProperties, body: body);
    Console.WriteLine("消息内容发送完毕:" + message);
}

如上设置消息优先级随时间逐段增高，运行代码，优先级高的消息后进入队列，消费者优先获取高优先级消息。注：当消费者消费消息的速度快过生产者发送消息的速度并且队列中没有消息堆积下，优先级设置则失去意义，消息到达队列就被消费了。

DotNet Core&RabbitMQ死信队列

Mon, 29 Aug 2022 10:00:00 +0800

过期时间

RabbitMQ可以为消息和队列设置过期时间Time To Live(TTL)。其目的即过期。

消息过期时间

消息存储在队列中时，如果想为其设置一个有限的生命周期，而不是一直存储着，可以为其设置过期时间。比如，一条消息，我想要三分钟内有效，三分钟后再接收到该消息就算过时了，如果在队列中存储已经超过三分钟，消费者再去接收就是过时了，那便没有意义了。

为消息设置过期时间可以从两方面着手，一是为消息本身设置过期时间，二是为消息的承载体队列设置过期时间。两者同时设置情况下取最短生命周期。

为消息设置

在BasicPublish方法中，可以设置BasicProperties中的Expiration来设置过期时间(单位为毫秒)。

var connFactory = new ConnectionFactory
{
    HostName = "xxx.xxx.xxx.xxx",
    Port = 5672,
    UserName = "rabbitmqdemo",
    Password = "rabbitmqdemo@test",
    VirtualHost = "rabbitmqdemo"
};
using (var conn = connFactory.CreateConnection())
{
    using (var channel = conn.CreateModel())
    {
        var queueName = "messagettl_queue";
        channel.QueueDeclare(queue: queueName, durable: false, exclusive: false, autoDelete: false, arguments: null);


        while (true)
        {
            Console.WriteLine("消息内容(exit退出):");
            var message = Console.ReadLine();
            if (message.Trim().ToLower() == "exit")
            {
                break;
            }


            var body = Encoding.UTF8.GetBytes(message);
            var basicProperties = channel.CreateBasicProperties();
            basicProperties.Expiration = "10000";//10秒
            channel.BasicPublish(exchange: "", routingKey: queueName, basicProperties: basicProperties, body: body);
            Console.WriteLine("消息内容发送完毕:" + message);
        }
    }
}

如此一来，设置消息生命周期为10秒，当超过该时间后，再由消费者去获取该消息，则获取不到，可以直接从Web界面看到，经过10秒后，消息过期(未启动消费者)。

DotNet Core&RabbitMQ消息存储可靠机制

Thu, 25 Aug 2022 10:00:00 +0800

前言

上篇讨论过消息投递和消息消费过程中如何确保可靠传输，也提及到消息到达RabbitMQ中到被消费前也需要可靠的留存，可因许多的不确定因素会影响着消息的存在与否。

消息中转点

生产者发送消息到RabbitMQ中，如果交换机根据自身类型和RoutingKey能够匹配到队列，则存入相关队列，但当匹配不到队列时，遇到两种情况而使得消息走向不同的方向，消息可能会丢失或是发回给生产者，这取决于生产者对消息的配置。

生产者设置了Mandatory且为true，则消息回退给生产者。
当生产者为设置Mandatory或是设置为false时，为了避免消息丢失，可以由交换机路由给备份交换机负责去搞定存储。

Mandatory

生产者发送消息时，可以设置一个参数mandatory，来决定消息到达RabbitMQ后，如果出现交换机根据自身类型及RoutingKey找不到合适的队列情况下，消息的一个走向。

当mandatory为true时，消息则返回给生产者。
当mandatory为false时，消息则被丢弃。

生产者代码

当在BasicPublish方法参数中设置mandatory为true且队列暂不声明时，仅有一个交换机，消息将会被返回。

var connFactory = new ConnectionFactory
{
    HostName = "xxx.xxx.xxx.xxx",
    Port = 5672,
    UserName = "rabbitmqdemo",
    Password = "rabbitmqdemo@test",
    VirtualHost = "rabbitmqdemo"
};
using (var conn = connFactory.CreateConnection())
{
    using (var channel = conn.CreateModel())
    {
        var exchangeName = "mandatory_publishsubscribe_exchange";
        channel.ExchangeDeclare(exchange: exchangeName, type: "fanout");
        while (true)
        {
            Console.WriteLine("消息内容(exit退出):");
            var message = Console.ReadLine();
            if (message.Trim().ToLower() == "exit")
            {
                break;
            }


            var body = Encoding.UTF8.GetBytes(message);
            channel.BasicPublish(exchange: exchangeName, routingKey: "", mandatory: true, basicProperties: null, body: body);
            Console.WriteLine("消息内容发送完毕:" + message);
        }
    }
}

生产者发送消息，交换机收到消息但无对应队列，消息被返回。为了直观的知道消息返回到了生产者，我们可以增加一个监听器，来监听返回的消息。

DotNet Core&RabbitMQ消息转发可靠机制

Tue, 23 Aug 2022 10:00:00 +0800

前言

生产者发送消息到了队列，队列推送数据给了消费者，这里存在一些问题需要思考下

生产者如何确保消息一定投递到了队列中
RabbitMQ 丢失了消息(下文暂不涉及这块)
队列如何确保消费者收到了消息呢

生产者可靠发送

执行流程

当生产者将消息发送出去后，如果不进行特殊设置，默认情况下，发送消息操作后是没有返回任何消息给生产者的，这时生产者是不知道消息有没有真的到达了RabbitMQ，消息可能在到达RabbitMQ前已经丢了。

对于这种情况，有两种解决方案来应对，

事务机制，该机制是AMQP协议层面提供的解决方案
发送方确认机制，这是RabbitMQ提供的解决方案

事务机制

可以将当前使用的channel设置成事务模式。借助如下与事务机制相关的三个方法来完成事务操作。

channel.TxSelect() 启动事务模式
channel.TxCommit() 提交事务
channel.TxRollback() 回滚事务

TXCommit

事务模式下，时序图中发布消息前后增加了一点动作，设置信道为事务模式与提交事务。如果TXCommit()调用成功，则说明事务提交成功，消息一定到达了RabbitMQ中。

TXRollback

当事务提交执行之前，由于RabbitMQ异常崩溃或其他原因抛出异常，则可以捕获异常，再执行TXRollback()，完成事务回滚。

生产者代码

在原有Basic代码基础上增加事务操作，此处先注释掉与事务有关的代码(16、34和40行)，并且在发送消息后设置异常模拟

var connFactory = new ConnectionFactory
{
    HostName = "xxx.xxx.xxx.xxx",
    Port = 5672,
    UserName = "rabbitmqdemo",
    Password = "rabbitmqdemo@test",
    VirtualHost = "rabbitmqdemo"
};
using (var conn = connFactory.CreateConnection())
{
    using (var channel = conn.CreateModel())
    {
        var queueName = "helloworld_tx";
        channel.QueueDeclare(queue: queueName, durable: false, exclusive: false, autoDelete: false, arguments: null);
        //channel.TxSelect();


        while (true)
        {
            Console.WriteLine("消息内容(exit退出):");
            var message = Console.ReadLine();
            if (message.Trim().ToLower() == "exit")
            {
                break;
            }


            try
            {
                var body = Encoding.UTF8.GetBytes(message);
                channel.BasicPublish(exchange: "", routingKey: queueName, basicProperties: null, body: body);
                if (message.Trim().ToLower() == "9527")
                {
                    throw new Exception("触发异常");
                }
                //channel.TxCommit();
                Console.WriteLine("消息内容发送完毕:" + message);
            }
            catch (Exception ex)
            {
                Console.WriteLine("消息发送出现异常:" + ex.Message);
                //channel.TxRollback();
            }
        }
    }
}

消费端代码保持不变(仅改动下队列名称) 因生产者已经将消息发送到了队列中，后触发了异常，实则已经和消息能不能到达队列无关了，在消费端也就正常消费了。

DotNet Core&RabbitMQ基本使用

Fri, 29 Jul 2022 10:00:00 +0800

队列模式

https://www.rabbitmq.com/getstarted.html

对以上几种模式进行简要分类，可以分成如下三类(RPC暂不考虑)

简单队列模式，单发单收，一对一模式
Worker模式，单发多收(一个消息一个接收者，多个消息多个接收者)，一对多模式
发布订阅模式，包括发布订阅、路由、通配符模式，这三种只是交换机类型不同

简单队列模式

队列作为中间件，在生产者和消费者中间承担消息传递的通道

创建两个控制台项目RabbitMQDemo.Basic.Producer和RabbitMQDemo.Basic.Consumer并安装Nuget包以支持对RabbitMQ操作

install-package rabbitmq.client

生产者代码

通过IConnectionFactory，IConnection和IModel来创建连接和信道。IConnection实例对象负责与RabbitMQ 服务端的连接，信道是在这连接基础上创建虚拟连接，通过复用来减少性能开销且便于管理。
通过QueueDeclare方法创建消息队列，设置消息队列本身的一些属性信息。
发送消息时调用BasicPublish来发送消息，通过exchange和routingkey参数满足大部分匹配消息队列的场景。

var connFactory = new ConnectionFactory
{
    HostName = "xxx.xxx.xxx.xxx",
    Port = 5672,
    UserName = "rabbitmqdemo",
    Password = "rabbitmqdemo@test",
    VirtualHost = "rabbitmqdemo"
};
using (var conn = connFactory.CreateConnection())
{
    using (var channel = conn.CreateModel())
    {
        var queueName = "helloworld";
        channel.QueueDeclare(queue: queueName, durable: false, exclusive: false, autoDelete: false, arguments: null);


        while (true)
        {
            Console.WriteLine("消息内容(exit退出):");
            var message = Console.ReadLine();
            if (message.Trim().ToLower() == "exit")
            {
                break;
            }


            var body = Encoding.UTF8.GetBytes(message);
            channel.BasicPublish(exchange: "", routingKey: queueName, basicProperties: null, body: body);
            Console.WriteLine("消息内容发送完毕:" + message);
        }
    }
}

消费者代码

消费端同样先创建连接和信道

AspNetCore&云效Flow持续集成

Sat, 25 Jun 2022 10:00:00 +0800

如今有了越来越多的持续集成工具，给的个人开发者的福利也是很足了，如无必要，自建工具有时只是作为练手了。

众多持续集成工具

现在可用的持续集成工具繁多，各大云服务商都推出了持续集成，甚至是一定条件内都是免费使用。

Azure DevOps 提供每个月1800 分钟的免费时长，支持单项目并行构建，5人以下。
GitHub推出的GitHub Action 每月2000分钟的构建时长。
华为云的 DevCloud 提供的编译构建5并发，每月600分钟，5人以下。
Gitee 推出了Gitee Go 单个代码仓库均可直接获得200分钟免费构建时长，永久有效！企业/组织/个人每月1000分钟免费构建时长自动到账。
腾讯云与 Coding 合作的Coding DevOps，初期Coding提供5人以下免费，每周200次持续集成次数，每次限时30分钟，并行任务数1个，中间变更到每月1000分钟持续集成时长，再如今七月份后变更到每月300分钟
阿里云的云效DevOps 最大并发任务数 6，运行时长 5400 分钟/月。人数不限！

云效的功能

云效DevOps中提供了如下功能可以使用，其中可根据实际开发中所用到的工具去比对选择。

此处，我只想白嫖流水线用于持续集成构建Docker镜像。对于Docker镜像的存储，阿里云提供了容器镜像服务(其本身也具备镜像构建功能，但受限)。对于个人开发者练手或是小微企业存储镜像应该算满足了。

对于代码的存储，可以选择云效 DevOps的代码管理(CodeUp)或是其他平台，这不影响流水线功能。

如此，简单的持续集成流程需要的功能算是齐全了。

项目设置

账号注册、申请这类就不提了，具体就是如何来快速完成一个持续集成流程的配置。

1、首先在代码仓库中新建项目，对于代码仓库的选择随意，我更倾向于使用 Gitee，当然也可直接使用云效提供的代码仓库。此处新建了一个仓库方便对照： https://gitee.com/530521314/Partner.TreasureChest/tree/master/Flow.Standard

2、新建 AspNetCore WebApi项目并增加 Dockerfile、gitignore文件，整理成常用的目录形式。

容器镜像服务设置

1、创建命名空间(3个命名空间共存300个镜像仓库)

2、创建镜像仓库，选择对应的命名空间，填写仓库信息。(镜像仓库下存放具体的镜像)

3、下一步中选择本地仓库后创建即可。

4、创建完毕会引导到该仓库下，当流水线跑完后选择镜像版本查看构建完的镜像。

云效流水线配置

开始使用流水线

新建流水线，可以按照语言类别选择，此处我使用空模板。

设置流水线源步骤

页面跳转后会提示选择代码源，此处我使用Gitee中的仓库，选择分支，添加即可。

增加镜像构建步骤

1、点击空任务更改其为镜像构建(或是其他名字)

2、添加任务步骤，此处可供选择的步骤很多，当前使用构建并推送到镜像仓库个人版

3、选择完毕会提示填写镜像仓库地址，该地址为上一步中的容器镜像服务地址，选择地域，镜像仓库。

4、配置目标镜像版本，默认是用日期作为镜像的标签。

理解RESTful Api设计

Tue, 24 May 2022 10:00:00 +0800

REST

REST(REpresentational State Transfer）是 Roy Fielding 博士于 2000 年在他的博士论文中提出来的一种软件架构风格(一组架构约束条件和原则)。在该论文的中文译本中翻译是"表述性状态移交"。

原则

网络上的所有事物都被抽象为资源
每个资源都有一个唯一的资源标识符
同一个资源具有多种表现形式(xml，json 等)
对资源的各种操作不会改变资源标识符
所有的操作都是无状态的

资源（Resources）

资源是一种信息实体或者说是一个具体信息，能够被想象出名字。比如多个图书馆，那么便是可使用的图书馆资源，而图书馆内，多个楼层，那么便拥有了多个楼层的资源，各楼层提供了不同服务，那么服务也是资源。在互联网中，可以用一个 URI（统一资源定位符）指向它，每种资源对应一个特定的 URI（如同一本书，按照书页码去定位哪一页，目的是定位资源）。访问这个特定 URI 便获取到了这个对应的资源。

表述（REpresentations）

资源的表述是一段对于资源在某个特定时刻的状态的描述，通过表述捕获资源，并在组件间(客户/服务器)移交该表述。表述有多种格式，如 HTML/XML/JSON/纯文本/图片/视频/音频等。具体的表述格式，可以在 HTTP 请求头信息中用 Accept 和 Content-Type 字段指定，请求/响应方向的表述通常使用不同的格式。

状态移交（State Transfer）

对于组件间而言(客户/服务器)，资源的请求是一个互动过程。通过表述捕获资源当前或是预期的状态，相当于获得了资源的状态。通过移交代表资源的表述，来将资源在组件的两者之间进行传递，进而改变应用状态。如当客户端获取了资源后，自身状态处于稳定，当再次获取资源后自身状态再次处于稳定。客户端操作并对服务端发起请求，在资源上执行各种动作而打破资源自身状态，达到客户端操作所期望状态。

RESTful Api

与 REST 相比多了一个 ful，就英语层面来说是一个形容词，RESTful 翻译成中文为“REST 式的”，满足了 REST 架构风格的应用程序设计的 Api 则便是 RESTful Api，即 REST 式的 Api。

以往 Api 设计

在 MVC 项目中，经常都是设计成动宾结构给 ajax 调用

/getCustomers
/getCustomersByName
/getCustomersByPhone
/getNewCustomers
/verifyCredit
/saveCustomer
/updateCustomer
/deleteCustomer

可有时却因为没有统一的规范，多人协作时，对于动词的描述上也没有统一，时长出现了类似如下的各类叫法，不能说这种情况有什么弊端，毕竟这种方式也是正常工作着。

AspNetCore&JWT认证授权

Sun, 17 Apr 2022 10:00:00 +0800

有时想快速搭建一个简单应用，并集成登录功能时，总是会被认证授权绕来绕去，一直想着要搞个授权中心，却把最为简单快捷的方式抛掷脑后。

认证与授权说来说去还是四个核心步骤，登录退出，登录有效后请求资源，请求人是谁与请求人有没有权限请求。

JWT

JSON Web Token（JWT）是目前最流行的跨域身份验证解决方案。其本身只是一种格式或是协议，集成到框架中，然后便按照这种格式或协议来传递信息。

当使用认证授权时，将具有用户信息的令牌以JWT格式的呈现，命名为Id token或是Access token。

项目准备

准备一个Asp.Net Core 6.0的WebApi(前端实现不考虑)。按照如上几个用例挨个实现(退出用例不考虑)

安装Nuget包

<ItemGroup>
  <PackageReference Include="Swashbuckle.AspNetCore" Version="6.2.3" />
 <PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="6.0.3" />
 <PackageReference Include="IdentityModel" Version="6.0.0" />
</ItemGroup>

生成JWT格式令牌

增加Account控制器

[ApiController]
[Route("[controller]")]
public class AccountController : ControllerBase
{


}

增加JwtOption

该部分信息用户Jwt格式中所需要的

public class JwtOptions
{
    public const string Name = "Jwt";


    public string Audience { get; set; }
    public string Issuer { get; set; }
    public double ExpiresMinutes { get; set; } = 30d;
    public Encoding Encoding { get; set; } = Encoding.UTF8;
    public string SymmetricSecurityKeyString { get; set; }
    public SymmetricSecurityKey SymmetricSecurityKey => new(Encoding.GetBytes(SymmetricSecurityKeyString));
}

服务注册

builder.Services.Configure<AuthConfigOptions>(builder.Configuration.GetSection(AuthConfigOptions.Name));

配置信息

appsettings.json中增加该块配置

理解OIDC协议和认证机制

Thu, 31 Mar 2022 10:00:00 +0800

当互联网应用越来越多，每个应用程序都实现了自己的身份存储、认证和授权，用户需要在应用上反复的注册与登录，体验糟糕，用户身份信息无法在多个应用间共享与同步。当使用企业应用时，企业提供了一系列应用，尽管是同一用户操作，但还是不得不切换注册与登录。

是否可以有那么一种方式，我在某个代理网站注册一个账号，如果登录其他网站时，其他网站可以到代理网站去获取信息。只要代理网站足够富有生命力，那么总是可以省略很多乏味的注册登录流程。

这些想法在技术的发展过程中出现了，如WS-Federation、SAML2.0、OpenID、OAuth、OIDC…

OpenID&OAuth发展历史

还有一些修订和扩展，此处就不体现了，主要是想聚焦于OpenID和OAuth是不一样的。

OpenID是面向身份认证，对用户身份进行认证判断是否有效。
OAuth是面向授权过程，在已知当前用户身份合法后，控制用户能够访问的资源，考虑保护被访问的资源。

OpenID

OpenID是一个去中心化的网上身份认证系统。对于支持OpenID的网站，用户不需要记住像用户名和密码这样的传统认证标记。取而代之的是，他们只需要预先在一个作为OpenID身份提供者（identity provider, IdP）的网站上注册。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份提供者。OpenID既解决了注册问题而又不需要依赖于中心性的网站来确认数字身份。

OpenID给用户提供一个统一网络身份，遵守OpenID网络身份，遵守OpenID协议的应用网站**（在OpenId术语里叫Relying Parties，即RP）需要用户登录时，引导用户到第三方OpenID身份提供方（OpenId术语里叫OpenID identity provider，即OP）**去认证，认证通过即登录成功。这样就省去了每个应用网站注册、登录的烦恼与乏味。解决了最开始提到的一个问题，各应用需要独立完成注册与登录流程，需要实现与维护独立的用户数据库。

OAuth

OAuth是一个授权协议，解决的是应用可以访问用户在另一应用上的某些授权资源，但此应用不需要知道用户在另一应用上的账户密码，即无需向另一应用透露用户的凭据便可以访问另一应用上受控的资源。

2006年11月，当时布莱恩·库克正在开发Twitter的OpenID实现。与此同时，社交书签网站Ma.gnolia需要一个解决方案允许使用OpenID的成员授权Dashboard访问他们的服务。这样库克、克里斯·梅西纳和来自Ma.gnolia的拉里·哈尔夫（Larry Halff）与戴维·雷科尔顿会面讨论在Twitter和Ma.gnolia API上使用OpenID进行委托授权。但他们讨论得出结论，认为OpenID没有完成API访问委托的开放标准。
2007年4月，成立了OAuth讨论组，这个由实现者组成的小组撰写了一个开放协议的提议草案。来自Google的德维特·克林顿获悉OAuth项目后，表示他有兴趣支持这个工作。
2007年7月，团队起草了最初的规范。随后，Eran Hammer-Lahav加入团队并协调了许多OAuth的稿件，创建了更为正式的规范。
2007年10月，OAuth Core 1.0最后的草案发布了。
2008年11月，在明尼阿波利斯举行的互联网工程任务组第73次会议上，举行了OAuth的BoF讨论将该协议纳入IETF做进一步的规范化工作。这个会议参加的人很多，关于正式地授权在IETF设立一个OAuth工作组这一议题得到了广泛的支持。
2010年4月，OAuth 1.0协议发表为RFC 5849，一个非正式RFC。
2012年10月，OAuth 2.0发布，正式发表为RFC 6749。OAuth 2.0是OAuth协议的下一版本，但不向下兼容OAuth 1.0。OAuth 2.0关注客户端开发者的简易性，同时为Web应用、桌面应用、手机和智能设备提供专门的认证流程。

Open ID Connect

OpenID团队本来希望用户使用OpenID来进行身份认证，但因为授权过程包括认证过程作为一部分，所以授权意味着经过了认证这一过程。由此，一些用户选择了OAuth身份认证的简易性，并且由于“管理用户凭据的任务可以委托给外部服务”以及“因为新用户注册过程可以省略，使用该服务的障碍变得更低”等优点而迅速占据主导地位，使用OAuth2.0作为身份认证的趋势变得流行。

OpenID团队不得不承认用户更喜欢OAuth2.0，因此，他们在OAuth之上定义了一个新的身份认证规范OpenID Connect(OIDC)，这个规范基于OAuth2.0进行了小幅扩展，在OAuth2.0上构建了身份层，使其可用作身份认证协议。

即OpenID Connect (OIDC) 是基于 OAuth 2.0 构建的身份认证协议。

OpenID+OAuth 2.0=OpenID Connect

OIDC主要术语

Claim: 声明信息，简要格式展示(如身份证上格式)。
Claims Provider: 声明信息提供方(如OAuth2.0中的Authorization Server能够返回Id token，其中携带着声明信息)。
End-User(EU): 人类参与者(完成认证活动的人)。
ID Token: 包含EU身份信息的声明(Claim)，以JWT(Json Web Token)格式进行存储传递。JWT具有自包含性、紧凑性和防篡改机制等特点。使得ID Token可以安全的传递给第三方应用并且容易被验证。

理解OAuth2.0协议和授权机制

Sat, 26 Feb 2022 10:00:00 +0800

无论是自然资源还是互联网上的资源，需要控制使用权与被使用权，以保护资源的安全、合理的使用和有效的管控。

项目中，我们需要控制的是用户资源，既要保证有效用户的合理使用，又要防范非法用户的攻击。如此，如何区分有效和非法就是我们需要考虑的问题，简单点，通过账号密码来区分，能够通过检测的便是有效用户。

可当项目越来越复杂，用户还想使用第三方应用，那么不能将账号密码交给第三方吧，同时，尽管通过账号密码检测了是有效用户，那么是否就能够访问资源、使用资源呢，这也未必。

种种因素下，OAuth(Open Authorization)作为一个安全、开放且简易的标准，方便我们在项目中协调资源、控制授权，以在用户、第三方应用和用户资源三者间形成一个有效的控制机制，而无需将用户的账号密码提供给第三方应用，且还能控制第三方应用对资源的访问与使用。

An open protocol to allow secure authorizationin a simple and standard method from web, mobile and desktop applications.

认证与授权

对于第三方应用想要访问被保护的资源，应当是使用授权访问，而这前提是要经过认证环节，毕竟认证成功，但不代表就有权限访问资源。OAuth更多的是侧重于如何实现授权来控制第三方应用能够访问资源。认证协议是基于其上的Open ID Connect。尽管OAuth的流程中存在认证部分内容，但不能说OAuth就是认证协议。

Authentication（认证）是验证用户(是第三方应用的使用者)的身份的凭据（账号和密码），通过这个凭据，系统得以知道你就是你，也就是说系统存在你这个用户。所以，Authentication 被称为身份/用户验证。
Authorization（授权）发生在 Authentication（认证）之后。其本身意思就很明了，它主要掌管我们访问系统的权限。比如有些特定资源只能具有特定的权限才能访问。比如手机浏览器想要访问底层摄像头，需要经用户允许访问才能获得授权，以此才能获取到具体资源。

OAuth历史

OAuth 的历史版本中有 OAuth 1.0 和 OAuth 2.0，其中 OAuth 1.0 在 2010 年发表为 RFC5849，OAuth 2.0 为 RFC6749，并且 OAuth 2.0 不向下兼容 OAuth 1.0，目前 OAuth 2.0 被广泛使用，因此这里不再对 OAuth 1.0 进行更多的描述。

OAuth的几种角色

Resource Owner：资源所有者，拥有资源的人，简单说就是谁在操作浏览器/App/小程序..
Resource Server：资源服务器，资源拥有者拥有的资源
Client：第三方应用，从资源所有者处获取授权，然后从资源服务器获取资源当不考虑OAuth协议，我们常见便是如上三种，想要第三方应用可以使用资源服务器的资源，又得把自身的账号密码交付给第三方应用，带来不安全。如此再加入一个角色，以平衡控制。
Authorization Server：授权服务器，提供给资源所有者完成授权并确定允许给第三方应用可以使用的资源范围与操作。由资源服务器方负责实现。如此一来，资源所有者将账号密码提供给授权服务器来完成验证，验证有效由授权服务器来负责提供能够代表身份的标识给第三方应用，这样一来降低了账号密码泄露的可能。

SpecFlow&环境搭建

Sun, 23 Jan 2022 10:00:00 +0800

BDD

Behavior Driven Development，即行为驱动开发，是敏捷开发技术之一，通过自然语言定义系统行为，以功能使用者的角度，编写需求场景，且这些行为描述可以直接形成需求文档，同时也是测试标准。

BDD 的目的不是自动化测试，但是 BDD 可以有效指导自动化测试，基于 BDD 的自动化测试相当于维护了一份需求活文档，对项目需求的维护和管理非常有价值。

SpecFlow

SpecFlow是一个测试框架，支持BDD的指导思想。SpecFlow源于Cucumber，概念和用途几乎一样，可以理解为SpecFlow是.Net平台下的Cucumber。基于Gherikin语法来定义用户场景。

安装扩展插件

打开Visual Studio 2022，顶部菜单扩展->管理扩展，安装Specflow插件

下载完毕，关闭VS，插件将提示被安装

安装完毕

创建测试项目

新建空白解决方案
创建一个待测类库
创建一个SpecFlow测试项目

在选择Test Framework时提供了四种选项，可依据实际使用选用

NUnit
xUnit
MSTest
SpecFlow+Runner 该方式需要跳转到微软账号获取认证，否则无法使用模板中已附带了相关的Nuget包，如上我选择NUnit

<ItemGroup>
  <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.0.0" />
  <PackageReference Include="SpecFlow.Plus.LivingDocPlugin" Version="3.9.57" />
  <PackageReference Include="SpecFlow.NUnit" Version="3.9.40" />
  <PackageReference Include="nunit" Version="3.13.2" />
  <PackageReference Include="NUnit3TestAdapter" Version="4.1.0" />
  <PackageReference Include="FluentAssertions" Version="6.2.0" />
</ItemGroup>

创建好的SpecFlow默认带了一个Demo 注意：默认创建的SpecFlow使用C#10，本地使用的C#9，有些功能不能使用，因此我将全局的命名空间及可空功能都关闭了，更改如下部分，删除即可

在ImplicitUsings中的全局命名空间，Copy到其他类中，删除ImplicitUsings.cs文件

为保持结构简洁，先删除Drivers和Support文件夹

AspNet Core&Agile Config配置中心

Mon, 27 Dec 2021 10:00:00 +0800

当服务逐渐的增多，对各服务的配置管理愈加重要，轻量级的配置中心，入手或是搭建都简单许多，基于.net core开发的轻量级配置中心AgileConfig，功能强大，上手简单。

https://github.com/dotnetcore/AgileConfig

AgileConfig架构图

AgileConfig配置端搭建

1、新建一个文件夹用来作为配置存储

mkdir agileconfig

2、新开数据库&配置账户名 3、下载镜像&创建容器

AgileConfig支持sqlserver，mysql，sqlite, PostgreSql，Oracle 五种数据库。依照实际使用的数据库类型选择,此处我这使用mysql。

sudo docker run \
 --name StarCityAgileConfig \
 -e TZ=Asia/Shanghai \
 -e adminConsole=true \
 -e db:provider=mysql \
 -e db:conn="Server=xxx; Database=xxx;Port=xxx;charset=utf8;uid=xxx;pwd=xxx;" \
 -p 9527:5000 \
 -v /agileconfig:/app/db \
 -d \
 kklldog/agile_config:latest

name：容器名，给定个容器名。
TZ：指定时区。
adminConsole：配置程序是否使用管理控制台。
- 如果为true则启用控制台功能，访问该实例会出现管理界面。
- 每个实例都可以选择使用管理界面，共用一套数据源只是呈现端口不同
- 默认账号为admin，首次登录需要设置密码，设置后多个管理界面都可以通用
db:provider：配置程序的数据库类型。
- 目前程序支持：sqlite，mysql，sqlserver，npgsql, oracle 五种数据库。
- 按照项目中允许的数据库使用即可。
- 首个节点启动后会创建数据表(相当好~)。
- db:env:{env}:provider，可以指定特定环境下使用某个数据库，如db:env:PROD.provider=sqlserver， db:env:DEVELOPMENT.provider=mysql
db:conn：配置数据库连接串。
- 按照不同的数据库类型设置不同的数据库连接字符串。
- 数据库使用第二步创建的库。

MinIO设置永久访问链接

Thu, 25 Nov 2021 10:00:00 +0800

MinIO 介绍

MinIO 是一个基于 Apache License v2.0 开源协议的对象存储服务。它兼容亚马逊 S3 云存储服务接口，非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，而一个对象文件可以是任意大小，从几 kb 到最大 5T 不等。

https://docs.min.io/cn/

有效期限制

文件上传到minio后，要进行分享时，从管理界面点击分享只能生成最多7 天有效期的链接。

或是使用sdk通过代码调用minio的Api的请求参数也是最大7天有效期。

超过期限再次访问便看不到了

有些资源是需要一直可以访问(公共资源)，需要对存储空间(Bucket)进行一番设置方可。

Bucket访问策略

存储空间(Bucket)默认策略有如下几种

Read Only - download
Write Only - upload
Read and Write - public
不设置 - none

从管理界面新建一个存储空间，然后查看策略，默认是为空的。

对存储空间(Bucket)的策略更改，可通过管理界面或是命令行形式更改目标桶的访问策略，当然了本质上最终都是对minio server的设置。

解决方案

minio server管理界面直接操作修改
minio相关的各语言SDK使用Api请求修改
minio提供的客户端修改

使用效果

当对存储空间(Bucket)按照如上三种之一设置访问策略后，直接通过如下格式访问即可

域名或ip:端口/桶名称/[文件前缀]/文件名

与直接点击分享链接相比，后缀那节加密算法和凭证参数就不用了

方案一：管理界面

新增一条策略，设置匹配前缀，再选择Read Only 或 Read and Write后点击添加即可。

当填写前缀 * 默认该存储空间(Bucket)下所有文件都可以访问
当填写特殊前缀对应该存储空间(Bucket)下特定这个前缀开头文件可以访问如此处设置以下d开头的前缀，那么便只有d开头的文件可以公开访问。

同时访问day.png和autumn.jpg，d前缀访问成功，其他跳转到文件目录下

方案二：SDK请求Api

此处以.Net为主，安装MinIO包，快速创建一个Bucket并设置下访问策略。

使用Synergy一套键鼠控制多台电脑

Sun, 17 Oct 2021 10:00:00 +0800

苦恼于不想买个无线鼠标操控两台笔记本，也不习惯用向日葵在两个电脑里切来切去，后来找到了这款软件，超方便解决我的需求。这篇文章通过使用跨平台Synergyc软件，实现一套键鼠同时操控两台电脑，条件是两台电脑连接在同一个局域网下（有线和无线皆可）。

Synergyc介绍

Synergy是一款能够让使用者仅用一套键鼠，就同时操控多部计算机的免费工具软件。可以在多台电脑之间共享鼠标、键盘、剪贴板。跨 Win、Linux、Mac。

https://github.com/symless/synergy-core

注：使用过程中，用起来是很方便的，但是由于Synergy开始转向收费了，下载仅是试用版，但它的分支Barrier保留了现有功能，也提供了更多功能，保持免费。

https://github.com/debauchee/barrier

Synergyc分为两个部分，Server端和Client端，Server作为主机，Client进行连接，达到使用主机的键鼠来控制从机的功能。这里举的例子是Window和linux，操作系统分别为Win10和Deepin。

Windows端

下载相应Windows版本，执行安装

https://www.brahma.world/synergy-stable-builds/

安装完毕后，进入程序，配置语言，注册码（直接略过了)。

配置服务端

此处我将常用的电脑作为服务端，执行配置，选择Server->设置服务端->拖动顶部电脑图标，按照实际使用的另一台或是几台电脑摆放位置，这是鼠标移出主屏的位置。

点击新拖动进来的电脑图标，弹框内设置该客户端名称（客户端安装synergy时，便是用到的这个名称，所以保持一致）

设置完毕后，点击底部开始按钮

完毕后服务端Synergy便正常运行了

Deepin端

执行命令安装即可，如果如下命令提示找不到相应的synergyc，请更新apt-get或者更换apt-get源。

sudo apt-get install synergyc

Deepin内提示我可以使用org.sys.synergyc，如此可简单了，输入命令按照提示Y就行了。

sudo apt-get install org.sys.synergyc

配置客户端

打开程序，选择语言，开始客户端配置，选择客户端，输入服务端IP地址，也就是上一步常用电脑的ip地址，完毕点击开始按钮即可。

客户端Synergy便在运行了

此时，按照配置客户图标时的方向移出主屏，便可以滑动到客户端，一套键鼠控制多台电脑。

参考链接

https://help.ubuntu.com/community/SynergyHowto

2021-10-17，望技术有成后能回来看见自己的脚步。

Docker&Nginx 设置SSL

Mon, 20 Sep 2021 10:00:00 +0800

SSL证书下载

此处从腾讯云处申请了个免费证书，申请流程很快，几分钟便搞定了。

https://console.cloud.tencent.com/ssl

在之前设置映射的路径处，创建一个文件夹用来保存证书文件

mkdir /docker/nginx/cert

然后将下载的证书上传并挪动到这个cert文件夹中(此处使用winscp工具直接挪动了)，稍后用于Nginx容器使用。

创建容器配置

创建一个新的容器并配置数据卷，注意端口号增加了443，且增加了证书的数据卷。

docker run \
--name nginxweb \
-p 8080:80 \
-p 443:443 \
-v /docker/nginx/nginx.conf:/etc/nginx/nginx.conf \
-v /docker/nginx/conf/conf.d:/etc/nginx/conf.d \
-v /docker/nginx/www:/usr/share/nginx \
-v /docker/nginx/logs:/var/log \
-v /docker/nginx/cert:/etc/nginx/cert \
-d \
nginx

更改Nginx.Conf

更改nginx.conf文件配置，增加一个server的块，增加对443的侦听和证书位置的配置，此处的位置是容器内的位置，也就是创建容器时指定数据卷那里的位置加上证书信息。

server {
 listen 443;
 server_name aspnetcore.online;
 ssl on;
 ssl_certificate /etc/nginx/cert/1_aspnetcore.online_bundle.crt;
 ssl_certificate_key /etc/nginx/cert/2_aspnetcore.online.key;
 ssl_session_timeout 5m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
 ssl_prefer_server_ciphers on;
 location / {
 proxy_pass http://119.91.109.91:80/;
 proxy_redirect default;
 }
}

再次请求，将http替换为https，带上域名重新访问，重定向到目标页中。

这样一来，反向代理和Https都设置成功了。

Docker&Nginx 安装与配置

Sun, 19 Sep 2021 10:00:00 +0800

创建Nginx容器

下载nginx镜像

docker pull nginx

创建nginx容器

docker run --name nginxweb -p 8080:80 -d nginx

这样一来nginx就创建好了，直接访问ip:8080就可以看到nginx安装好的页面

4、改变配置实现更多功能，这种情况下得进入容器更改配置信息

docker exec -it nginxweb /bin/bash

配置文件在容器内/etc/nginx/路径下的nginx.conf和conf.d文件夹内的default.conf文件但是默认使用vi或vim去修改是没有用的，因为没得，得去安装，这种情况下就很麻烦，更常用的是做个数据卷，将容器内文件映射到容器外，这样改变主机文件就改变了容器内文件，方便些。

如果不嫌麻烦在容器内改完配置文件后，重启容器

docker restart nginxweb

这样不是很方便，先删除容器。

docker stop nginxweb
docker rm nginxweb

挂载配置文件

在主机上设置配置文件，以方便主机直接修改nginx容器内的配置信息。

建立映射文件夹

先建立几个文件夹用于存放数据卷的

mkdir -p /docker/nginx
mkdir -p /docker/nginx/conf
mkdir -p /docker/nginx/www
mkdir -p /docker/nginx/logs

这几个文件对应着nginx内的配置文件，如此下来，重新创建nginx容器并指定数据卷，这样当我们修改本地文件时候，也就是nginx容器内部文件修改了。 2. 创建一个临时容器用来复制配置信息

docker run --name nginxweb -p 8080:80 -d nginx

先将临时容器内已有的配置信息拷贝到主机文件中

docker cp nginxweb:/etc/nginx/nginx.conf /docker/nginx
docker cp nginxweb:/etc/nginx/conf.d /docker/nginx/conf
docker cp nginxweb:/usr/share/nginx/html /docker/nginx/www
docker cp nginxweb:/var/log/nginx /docker/nginx/logs

详细描述

精简ABP的模块依赖

Thu, 19 Aug 2021 10:00:00 +0800

ABP的模块非常方便我们扩展自己的或使用ABP提供的模块功能，对于ABP自身提供的模块间的依赖关系想一探究竟，并且试着把不必要的模块拆掉，找到那部分核心模块。本次使用的是AspNetBoilerplate。

源码下载

从Github下载ABP源码后，进入src文件夹，提供的大部分模块都在此中。很多工具也经ABP封装，个人认为是方便了集成使用且融入到ABP这个框架。

src文件夹中的类库有几种类型如.net standard(为了兼容.net framework)、.net 5 、.net framework的。

我的想法是最小的模块引用，因此按照如下两个条件移除

移除.net framework的，只专注于.net core所需要的。
移除Zero模块。

精简模块

整理后也就是剩下这部分，这样看仍然感觉有很多模块，但对于其中大部分来讲更多的是将一些工具封装了下，比如从SignalR，AutoMapper，Log4Net，Dapper，EFCore等等。

通过整理这部分类库间的依赖关系，(此图中去掉了Dapper、NHibernate、MemoryDB和MongoDb)，如此一来分类便清晰许多，一眼便可以识别出Abp这一核心模块。哪些模块的提供的功能是什么，这样也方便查看。

我们再来建立一个项目来直接对该部分类库引用，而不是走Nuget包的方式。先依赖需要的最基本的模块，比如Abp、Abp.WebCommon和Abp.AspNetCore等几个模块，能够保障最基本的请求功能，甚至于读取数据库的ORM工具都不纳入进来。

依赖核心模块

此处将Log4Net作为需要的模块纳入进来，因为Abp中部分地方记录日志时候需要相应的实现类，当然也可以使用其他日志组件如NLog等，但需要实现Abp中封装好的抽象类，可参考如下链接：https://www.cnblogs.com/donaldtdz/p/8213440.html

新建一个空白解决方案AbpIntegrationDemo.sln

建立一个module文件夹用于放置上述最基本模块。
建立一个src文件夹中用于搭建分层结构。

对于src中的每一层所依赖的项目按照层次关系及依赖关系，其中核心层Domain依赖Abp模块，Application和Infrastructure都依赖核心层也就都对Abp模块有了依赖关系了。

如此一来，最为基本的依赖便完成了，各层内增加相应的Module，按照Abp模块化构建方式将这些模块贯穿起来。比如AbpIntegrationDemo.Admin，将依赖的模块，需要注入的、配置的东西加入进来，此处部分直接从Abp start up中搬过来的，还可以再精简一下，部分内容目前是没有用到的。

[DependsOn(
 typeof(AbpIntegrationApplicationModule),
 typeof(AbpIntegrationInfrastructureModule),
 typeof(AbpAspNetCoreModule)
 )]
public class AbpIntegrationAdminModule : AbpModule
{
 private readonly IWebHostEnvironment _env;
 private readonly IConfiguration _appConfiguration;


 public AbpIntegrationAdminModule(IWebHostEnvironment env, IConfiguration appConfiguration)
 {
 _env = env;
 _appConfiguration = appConfiguration;
 }


 public override void PreInitialize()
 {
 Configuration.DefaultNameOrConnectionString = _appConfiguration.GetConnectionString(AbpIntegrationDomainConsts.ConnectionStringName);
 Configuration.Modules.AbpWebCommon().SendAllExceptionsToClients = false;
 }


 public override void Initialize()
 {
 IocManager.RegisterAssemblyByConvention(typeof(AbpIntegrationAdminModule).GetAssembly());
 }


 public override void PostInitialize()
 {
 IocManager.Resolve<applicationpartmanager>()
 .AddApplicationPartsIfNotAddedBefore(typeof(AbpIntegrationAdminModule).Assembly);
 }


 public override void Shutdown()
 {
 base.Shutdown();
 }
}

在此基础上，按照需要的模块，如EF Core、Redis、Hangfire、AutoMapper等等，也只需要引用进来了，至少到现有地步，对于Abp模块的依赖及最为核心的模块应该是清楚了，而对于看到很多人说Abp重的说法，个人感觉是不是看到依赖的模块太多而有种复杂的感觉，实则有很多是工具模块，即使不使用Abp，实际开发中也会使用进来。 https://gitee.com/530521314/Partner.TreasureChest/tree/master/AbpIntegrateDemo

AspNetCore&MassTransit Courier实现分布式事务

Mon, 19 Jul 2021 10:00:00 +0800

在之前的一篇博文中，CAP框架可以方便我们实现非实时、异步场景下的最终一致性，而有些用例总是无法避免的需要在实时、同步场景下进行，可以借助Saga事务来解决这一困扰。在一些博文和仓库中也搜寻到了.Net下实现Saga模式的解决方案MassTransit，这就省得自己再造轮子了。

分布式事务

分布式系统中，分布式事务是一个不能避免的问题，如何保证不同节点间的数据一致性。举个常见的例子，下订单、减库存、扣余额，三者在单个节点时，可以借助本地事务，实现要么成功要么失败。而当三者处于不同节点时，又参杂了如网络环境、节点自身环境、服务环境等各种因素，使得三个节点想要实现要么成功、要么失败就增加了许多困难。

CAP理论和BASE理论很好的诠释了这一问题，也有了许多的解决分布式事务的方案，如2PC、3PC、TCC、本地消息表、Saga等一系列解决方案，面对不同场景、不同要求等可选择不同的解决方案。

	数据一致性	容错性	复杂性	性能	维护成本
2PC	强	低	中	低	低
3PC	强	低	高	低	中
TCC	弱	高	高	中	高
本地消息表	弱	高	低	中	中
MQ事务	弱	高	低	高	中
Saga事务	弱	高	高	中	高

在之前提到过一个基于本地消息表的CAP框架，借助最终一致性很方便的解决了异步非实时请求下的分布式事务，而对于大部分场景虽然可以直接或者妥协方式使用着异步非实时，如同步实时场景的下订单且减库存变更到异步非实时场景的下订单后发事件减库存，但是总有那么一些场景，不得不去考虑同步实时请求下的分布式事务。

Saga模式

Saga模式又叫做长时间运行事务（Long-running-transaction）, 由普林斯顿大学的 Hector Garcia-Molina和Kenneth Salem 1987年发表的论文《Sagas》。核心思想是将长事务拆分为多个本地短事务，通过保证所有短事务的成功或失败来决定整体的成功或失败，由Saga事务协调器协调管理，所有节点执行成功，则成功，如有节点失败，则反向执行前置节点的补偿操作。

每个Saga事务由一系列幂等的有序子事务(sub-transaction) Ti 组成。
每个Ti 都有对应的幂等补偿动作Ci，补偿动作用于撤销Ti造成的结果。

执行过程

当正常执行时，依照T1、T2、T3三个短事务正常执行下去，直到最后一个Tn事务执行完毕，宣告整个事务的成功。

而当执行到某个Tj出现故障时，则反向补偿之前的Tj-1..T1,每个对应的补偿操作Cj-1…C1，其中Tj事务由于在执行阶段就已失败，所以Tj对应的补偿动作Cj不需要执行，即也确定了最后一个Tn事务可以不设置补偿动作Cn。

恢复策略

向前恢复(forward recovery)：对于Ti事务的执行，部分场景下可能因为数据库的连接、网络的波动等导致短暂的失败，对Ti事务重试执行，以确保整个事务的执行，如执行T1, T2, T3，当执行T3失败时，不直接宣告失败，对T3执行重试以排除部分不稳定因素，如在若干次重试无效后，再考虑向后恢复。

MassTransit中Request&Response基本使用

Tue, 29 Jun 2021 10:00:00 +0800

MassTransit 是一个自由、开源、轻量级的消息总线基于.Net框架, 用于创建分布式应用程序。方便搭建基于消息的松耦合异步通信的应用程序和服务。MassTransit 在现有消息传输上提供了一组广泛的功能, 从而使开发人员能够友好地使用基于消息的会话模式异步连接服务。基于消息的通信是实现面向服务的体系结构的可靠和可扩展的方式。

官网地址：http://masstransit-project.com/

发布订阅模式

这种场景十分常见，发送一个消息(或事件)到消息队列中，有一个或是多个订阅方对预期的消息接收处理。

基于需要搭建了两个WebApi程序，用于模拟发送方和订阅方，其中的RabbitMQ已预先搭建好了，只在程序中引用包配置下即可。

<PackageReference Include="MassTransit" Version="7.2.0" />
<PackageReference Include="MassTransit.AspNetCore" Version="7.2.0" />
<PackageReference Include="MassTransit.RabbitMQ" Version="7.2.0" />

发布端配置

在Startup中增加MassTransit需要的服务及初始化配置。

对RabbitMQ的连接地址端口、虚拟主机、访问账号密码等系列配置。
对发送方需要发送的消息初始化一个请求客户端，配置请求信息及推送到MQ的地址。

services.AddMassTransit(x =>
{
    x.UsingRabbitMq((context, cfg) =>
    {
        cfg.Host(Configuration["RabbitmqConfig:HostIP"], ushort.Parse(Configuration["RabbitmqConfig:HostPort"]), Configuration["RabbitmqConfig:VirtualHost"], h =>
        {
            h.Username(Configuration["RabbitmqConfig:Username"]);
            h.Password(Configuration["RabbitmqConfig:Password"]);
        });
    });
    x.AddRequestClient<ValueEntered>(new Uri(GetServiceAddress("events-valueentered")));
});
services.AddMassTransitHostedService();

为了快速了解，使用Controller在Action中发起对MQ的消息推送

[ApiController]
[Route("[controller]")]
public class ValueController : ControllerBase
{
    readonly IPublishEndpoint _publishEndpoint;
    public ValueController(IPublishEndpoint publishEndpoint)
    {
        _publishEndpoint = publishEndpoint;
    }
    [HttpPost]
    public async Task<ActionResult> Post(string value)
    {
        await _publishEndpoint.Publish<ValueEntered>(new
        {
            Value = value
        });
        return Ok();
    }
}

订阅端配置

订阅端也创建一个WebApi应用，在Startup中增加MassTransit的服务，使用到的Nuget包和发布端一样。

Docker&Portainer升级版本

Sun, 30 May 2021 10:00:00 +0800

前言

为了备考系分，好久没对服务器操作了，空闲了很长时间，之前看着 Portainer 一直提示更新也没有理会，现在解放了，开始升级一波。

当前环境

系统：CentOS

Portainer 原有版本：1.24.0

在 Portainer 安装时候是指定了数据卷的，这样一来，更新 Portainer 只需要下载新的 Portainer 的镜像，删除原有容器即可，原先的记录信息都在数据卷中。

部署方式

先确定是直接用单个容器安装命令启的容器还是走的集群命令起的容器

docker service list

比如我本地是用集群部署方式

单机部署

如直接使用镜像启动，则使用单个容器名关闭

docker stop portainer的容器名或容器Id

删除容器

docker rm portainer的容器名或容器id

可查看下容器确定下是否已经删除

docker ps -a

删除镜像

docker rmi portainer的镜像名或镜像Id

如仍沿用单机部署方式，则直接拉取新版本镜像

docker pull portainer/portainer-ce

启动镜像，登录输入账号密码即可

docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock --restart=always --name portainer portainer/portainer-ce

集群部署

如采用服务方式启动，则移除服务一并删除容器

页面上选中 portainer 相关的服务删除后弹框如上，一并将容器也删除。

或是使用命令删除

docker service rm portainer的服务名或服务Id

可查看下容器和服务情况确定下是否已经删除 portainer

docker ps -a
docker service list

删除镜像

docker rmi portainer的镜像名或镜像Id

如采用集群部署，则使用集群部署的命令(单机也可采用，方便使用到提供的 webhook 功能)

curl -L https://downloads.portainer.io/portainer-agent-stack.yml -o portainer-agent-stack.yml
docker stack deploy -c portainer-agent-stack.yml portainer

查看当前服务、镜像和容器，可以发现都存在了，容器直接启动

AspNet Core&CAP实现分布式事务

Wed, 28 Apr 2021 10:00:00 +0800

需要注意的是标题中的CAP不是指的CAP理论，而是园区大神杨晓东实现的框架，CAP框架基于本地消息表用最终一致性实现分布式事务。

本地消息表

首先我们考虑一个场景，在将用户信息更改后，需要发送一条消息到消息队列、缓存或是写入到其他库中。这个过程涉及到一个本地库与MQ、本地库与Cache或是本地库与其他库两者之间的事务问题，不能用简单的数据库事务控制了。

这种分布式事务下，常用的解决方案有2PC、3PC等强一致性保证的，也有TCC、Sagas模型、本地消息表、内嵌本地消息表的MQ等最终一致性保证的。

而在很多异步场景下，允许系统存在短暂的不一致，只需达到最终一致，比起强一致性那种刚性事务，采用柔性事务，在很多场景下更有利于我们去实现。

执行过程

在使用CAP框架前，先熟悉下作为分布式事务解决方案之一的本地消息表工作过程。

消息发起方(如图左侧部分)和消息接收方(如图右侧部分)，先额外建一套消息表，用来记录及跟踪消息内容及状态。
当有请求到消息发起方时，处理完业务逻辑发布消息将业务数据和消息数据一同提交到本地表中，此时为本地事务。
本地事务没有问题后，将消息发送到MQ传递给消息消费方。如果消息发送失败，会进行重试发送。
消息消费方，接收并处理消息，完成自己的业务逻辑，此时为消息消费方本地事务，如果本地事务完成，则更改接收消息的状态，更改本地，如果处理失败，那么可再次重试执行。
最终，左侧事务与右侧事务达到最终一致。

CAP框架

CAP是一个在分布式系统中（SOA，MicroService）实现事件总线及最终一致性（分布式事务）的一个开源的 C# 库，具有轻量级，高性能，易使用等特点。

具有 Event Bus 的所有功能，提供了更加简化的方式来处理EventBus中的发布/订阅。
具有消息持久化的功能，当服务进行重启或者宕机时，可以保证消息的可靠性。
基于本地消息表实现了分布式事务中的最终一致性。

集成了可视化页面方便观察消息状态。

提供了一系列Nuget包以选择需要的工具接入。

第一个包DotNetCore.CAP为必须要安装的。
可以依据消息队列的不同选择用RabbitMQ、Kafka或是AzureServiceBus等。
根据服务使用的数据库情况选择需要将本地消息表落库，可以选择SqlServer、MySql、PostgreSql、MongoDB等，或是直接使用内存存储，方便快速实践。

场景案例

依照EShopOnContainers中的一张图来实现一个例子，用户更新用户信息，将更新的部分通过事件发送到消息队列中，下游的购物车和订单服务侦听到消息，更改买家信息。

在此基础上行，设计三个上下文，并分别集成CAP,借助RabbitMQ作为消息队列，对于UserService、BasketService和OrderService,都直接使用了数据库（当然可以不仅限于数据库）。

服务建立

项目创建

开始建立几个服务，新建空白解决方案，依次建立三个WebApi项目，并移除默认的控制器。

简单设计下，在三个服务中创建三个DbContext，对应三个独立的数据库。

UserService中创建UserInfo实体及UserDbContext
BasketService中创建Basket实体及BasketDbContext
OrderService中创建Order实体及OrderDbContext

安装Nuget包

在三个服务中均安装完如下选中的包，此次Demo中为方便快速实践，选择RabbitMQ作为消息队列，MySql作为数据库存储。

对于EFCore及MySql包，安装了如下几个包

Microsoft.EntityFrameworkCore
Microsoft.EntityFrameworkCore.Design
Microsoft.EntityFrameworkCore.Tools
Pomelo.EntityFrameworkCore.MySql

注意此处EFCore中MySql版本和CAP中MySql版本两者间依赖的MySqlConnector不一致会有点问题

配置服务

需要对CAP进行设置，比如使用的是什么数据库、什么消息队列及配置下消息队列参数，这一系列初始化设置在Startup.cs中配置好。

ConfigureService中配置DbContext和CAP服务

Configure中CAP的引入中间件

利用EFCore的迁移命令生成下数据库迁移脚本，将DbContext内实体生成到数据库中
单个服务启动后，CAP组件会将内置表创建到数据库中。

服务全部启动后，RabbitMQ Client会自动注册到RabbitMQ Server中同时创建好给定的Exchange(不给定则使用默认值)，存在订阅的服务则注册队列绑定到给定的Exchange下。

发布事件

在 UserService中UserController 中注入ICapPublisher，使用Patch接口更新一个Address，然后使用ICapPublisher发布一条消息。

RabbitMQ介绍&Docker安装

Sun, 28 Mar 2021 10:00:00 +0800

MQ介绍

MQ概念

MQ: Message Queue，译为消息队列，本质是个队列，具有先进先出特性，应存放的是消息，因此对其称呼为消息队列。

MQ作用

解耦利器

借助MQ，将多个服务彼此隔离，服务间只清楚MQ的存在，而不需要知道彼此的存在。

异步

如抢购场景，同步请求时，需要完成订单，减库存，付款一系列操作，实时性要求强，技术要求也更高，而在异步请求下，下了订单后，立马将请求返回，等待查询处理结果，当MQ另一侧的服务处理完毕后，才会知晓是否购买成功。此时对于下订单这块的服务，异步下可大幅提高可用性。

削峰/限流

继续考虑如上场景，当抢购量大时，存放在MQ内的消息众多，而处理消息的服务可以依据自身机器性能，程序性能去处理符合自身处理能力的消息数量，如同步场景下，可能出现的局面是将洪水引入小沟渠。

MQ局限

当上游服务需实时关注执行结果时，使用MQ反而不利，借助MQ更多的是完成时间换空间的活。

常见应用案例

注册时发送邮件或发送短信
日志分析使用，多个服务产生的数据发送到中间件发送到分析服务。
消息复制，用于跨机房数据传输、搜索、离线数据计算等。
延迟消息发送和暂存，把中间件当成可靠的消息暂存地。接受消息，暂时先不发送。

常见MQ中间件

比较流行的有 RabbitMQ、ActiveMQ、ZeroMQ、kafka，阿里开源的RocketMQ，微软的Service Bus等。

RabbitMQ介绍

RabbitMQ

RabbitMQ 是实现 AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 RabbitMQ 主要是为了实现系统之间的双向解耦而实现的。当生产者大量产生数据时，消费者无法快速消费，那么需要一个中间层。保存这个数据。

AMQP协议

AMQP，即 Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。

RabbitMQ特点

RabbitMQ 是一个开源的 AMQP 实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

具体特点包括：

可靠性（Reliability）RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。
灵活的路由（Flexible Routing）在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。
消息集群（Clustering）多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。
高可用（Highly Available Queues）队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。
多种协议（Multi-protocol）RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等。
多语言客户端（Many Clients）RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。

Lambda&Expression Tree

Sat, 27 Feb 2021 10:00:00 +0800

Lambda演变历史

.Net Framework 1.0/1.1

public class EvolutionHistory
{
 public delegate void CustomDelegate(string param);

 public void Test()
 {
 CustomDelegate customDelegate = new CustomDelegate(DoWork);
 customDelegate.Invoke("test");
 }

 private void DoWork(string param)
 {
 Console.WriteLine(param);
 }
}

.Net Framework 2.0

匿名方法，delegate关键字出现，简化了委托实例化参数

public class EvolutionHistory
{
 public delegate void CustomDelegate(string param);

 public void Test()
 {
 CustomDelegate customDelegate = new CustomDelegate(delegate (string param)
 {
 Console.WriteLine(param);
 });
 customDelegate.Invoke("test");
 }
}

.Net Framework 3.0

Lambda表达式出现

理解领域驱动设计

Mon, 18 Jan 2021 10:00:00 +0800

前言

什么是领域，我习惯描述的是制药领域、环境领域、建筑领域、金融领域等，而在领域内，各种业务规则、业务知识盛行，如何有效的把控规则的变化，应对复杂知识，有一个很关键的四字词语，分而治之。分治法在很多场景下体现了其强大的作用力。领域本身很大，那就拆分，得到更小的领域，也即子域，如同递归调用一般，将一个复杂问题拆分单独求解，而最终将解汇总得到复杂问题解。

怎么拆，拆成怎么样合适，依据什么拆，这些在领域驱动设计中有了一套答案，虽然领域驱动设计不是银弹，但可以说的上是一套极好的系统方法论或称为架构设计的方法论。

领域驱动设计常以战略设计与战术设计来将整个领域展现的淋漓尽致，其作用范围既面向业务也面向技术。从战略角度(个人更喜欢称其为上帝视角)去规划系统、划分领域。而从战术角度则从技术层面来指导我们该如何去设计。

战略设计

战略设计主要从高层俯视(上帝视角)我们的软件系统，就如同玩即时战略游戏般，可以一览地图全貌，以此来决定我们是要进攻还是防守哪个方向，同样，在软件中我们也可以以此来划分领域，确定权重方向。

统一语言

提炼领域知识，怎么个提炼法，千万条罗马路，各有各的看家本领。像事件风暴方法，用例分析方法，用户故事，甚至是开大会，各种讨论会等，最终目的都是提炼出领域知识，而提炼过程中，达成描述上的一致性，包括系统目标、系统范围及系统所具有的功能。

这不是领域驱动设计所独有的，但却是软件开发中所必须的，为领域专家、业务分析人员、编码人员和测试人员等团队所有成员交流时构建统一频道。

领域/子域

领域拆分

对于领域这个概念，习惯性会想到制药领域、环境领域、金融领域等这些概念，而领域本身所描述的是范围，是如同现实世界般的复杂，无边际。借助分治法，将问题逐级细分来降低业务和技术复杂度，将这复杂的世界划分出清晰的边界来，反过来控制着划分后不那么复杂的世界，也既领域拆分出细化后的子领域。

子域划分

在实际解决问题时，我们也习惯将问题拆分，而怎么拆，基于什么原则拆，可能会依据相关性，权重，甚至分类原则等，对于系统而言，会从架构方面考虑，基础设施考虑等，在领域驱动设计中，更偏向基于业务拆分，降低业务复杂度，也分离技术实现的复杂度，依照业务拆分后的子领域，本身存在权重上的差异，依照重要性和功能划分为三类，投资占比也就有所不同。

核心域：其所体现的是核心服务，是代表着产品的核心竞争力。
支撑域：其所体现的是支撑服务，没它不行，但又达不到核心的价值，围绕着产品内部所需要，但又不能单独变更为第三方服务，即它不是一个通用的服务。
通用域：其所体现的中间件服务或第三方服务。本身可以通过现有的解决方案集成来完成的服务。

限界上下文

深入到一个子域中，又是一片小天地，在这天地中，却又还是存在着因语义与语境上的差异，让一些概念在这子域中显得额外尴尬。在一个领域 / 子域中，我们会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。

其本质上是限界+上下文，引用到张逸老师的一句话

上下文（Context）其实是动态的业务流程被边界（Bounded）静态切分的产物。对于子域与上下文间的关系，看到很多书籍或是文章中所描述的都不一样，这块的争论也没有一个最终答案，个人更倾向于子域中划分上下文，从拆分角度来讲，这样理解更加简单。

上下文识别

对于上下文的识别，没有可遵循的标准可走，从不同的角度切入将会识别到不同的上下文，可从张逸老师的领域驱动设计实践中窥之一二，以业务复杂度、管理复杂度和技术复杂度出发，面对这三个角度去依次分析，从业务视角、工作视角、应用视角去识别，进而识别出准确的上下文，通过不断的分析斟酌考虑，逐渐识别出符合当前预期的上下文，如在实际操作环节发觉当前上下文的设计显得不那么合理，还可再进行变动、拆分上下文。

但需注意的一个是，我们识别上下文的目的是什么，是为了控制上下文，准确的说是为了控制上下文的边界、大小，是为了保住我们所守护的上下文不会因过度成长变大而奔溃，亦或因上下文过度缩减而失去价值，保证上下文内一切的稳定，上下文与上下文间交互的可用性，也或者是当我们退出上下文时，交付出来的上下文是非常可观的，而不是一个烂摊子。

上下文映射

规划了这么多限界上下文，该如何穿针引线将这些上下文串起来便是一个问题了，用例场景的完整实现往往是由多个上下文的协作完成的，怎么去组织这些上下文，领域驱动设计提到的几种方式及软件工程中常用模式。

合作关系：一荣俱荣，一损俱损。
共享内核：上下文间共享领域实体。
客户方-供应方：下游客户依赖于上游供应方。
遵奉者：下游客户顺应上游供应方。
各行其道：没有关系的关系，相互隔离。
防腐层：在下游上下文与上游间增加一道屏障，以此来隔绝与上游的直接交互保护下游。
开放主机服务：在上游与下游上下文间增加一道协议，以此来规范下游对上游的集成。
已发布语言：发布方上下文发布一份包含丰富文档的信息交换语言，消费方上下文翻译并使用。

这些模式其本质是为了协作，为了满足用例场景下对多个限界上下文的调用，通过上下文映射图，可以清楚知晓运行逻辑。为了实现上下文映射，简单讲就是如何将两个上下文连贯起来，常借助的方式是诸如 RPC、HTTP、消息队列等，依照上下文间映射类型，挑选一件趁手的工具。

分层架构

我们通常喜欢对各种事情归纳总结，如文章的层次分明，如建筑结构高低有序、疏密有致，给人一种各处所关注的信息视角不同，而组合起来显得如此美妙。软件中同样运用着分层来隔离关注点，以此来隔离每层的演进速率。

当我们考虑限界上下文时，不仅需要去考虑其内部的领域设计，还得从其应用边界本身考虑，限界上下文是属于架构设计层次，主要针对的是后端架构层次的垂直切分，按照经典 DDD 的分层结构来看，共分为如下四层：

User Interface 为用户界面层，向用户展示信息和传入用户命令。这里指的用户不单单只使用用户界面的人，也可能是外部系统，诸如用例中的参与者。
Application 为应用层，用来协调应用的活动，不包含业务逻辑，通过编排领域模型，包括领域对象及领域服务，使它们互相协作。不保留业务对象的状态，但它保有应用任务的进度状态。
Domain 为领域层，负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心，领域模型位于这一层。
Infrastructure 为基础实施层，提供公共的基础设施组件，如持久化机制、消息管道的读取写入、文件服务的读取写入、调用邮件服务、对外部系统的调用等等。

值得注意的是，给定的分层方式仅仅是逻辑上的分层，而对于实际的物理分层，却又有所不同，但遵守一个前提为好，即限界上下文的边界高于分层的边界。诸如如下两种开发中常见的代码组织方式，都可见到。一种是基于技术分层，而另一种更偏向基于业务分层。

方式一

- application
 - productcontext
 - ordercontext
 - ...
- domain
 - productcontext
 - ordercontext
 - ...
- infrastructure
 - productcontext
 - ordercontext
 - ...

方式二

Electron安装打包指南

Fri, 04 Dec 2020 10:00:00 +0800

当前环境Debian Linux-Deepin

安装Node

直接下载

命令下载

下载

wget https://nodejs.org/dist/v14.15.1/node-v14.15.1-linux-x64.tar.xz

解压，解压后在当前盘多了个文件夹node-v14.15.1-linux-x64.(可自行改名)

sudo tar -zxvf node-v14.15.1-linux-x64.tar.gz

建立软链接

sudo ln -s /盘路径/node-v14.15.1-linux-x64/bin/node /usr/local/bin/
sudo ln -s /盘路径/node-v14.15.1-linux-x64/bin/npm /usr/local/bin/

查看版本

node -v
npm -v

卸载Node

1、卸载npm

sudo npm uninstall npm -g

2、卸载node

sudo apt-get remove nodejs npm -y

3、检查是否还存在

进入/usr/local/lib 删除所有 node 和 node_modules文件夹
进入/usr/local/include 删除所有 node 和 node_modules 文件夹
进入 /usr/local/bin 删除 node 的可执行文件

sudo rm -rf /usr/local/lib/node*
sudo rm -rf /usr/local/include/node*
sudo rm -rf /usr/local/bin/node*
sudo rm -rf /usr/local/node*

设置淘宝镜像源

npm config set ELECTRON_MIRROR=https://npm.taobao.org/mirrors/electron/

查看当前镜像源

代码模型组织方式

Sun, 22 Nov 2020 10:00:00 +0800

结构划分迷雾

Asp.Net Boilerplate中默认项目结构是如下所示(项目代号Gravel)，每层都是一个单独的类库或是应用程序。

- Gravel.sln
 - Gravel.Web
 - Gravel.Application
 - Gravel.Core
 - Gravel.EFCore

在这种固有分层方式下，ABP没有指明要采用什么形式去划分限界上下文，是采用文件夹隔离形式还是采用类库隔离形式，并没有严格说明。 注意：具体是在应用层领域层基础设施层中需要隔离限界上下文。

文件夹隔离

如采用文件夹隔离形式，则解决方案结构如下，在每一层中建立文件夹形式以此来划分限界上下文的边界。

- Gravel.sln
 - Gravel.Web
 - Gravel.Application
 - OrderCenter
 - ProductCenter
 - CustomerCenter
 - Gravel.Core
 - OrderCenter
 - ProductCenter
 - CustomerCenter
 - Gravel.EFCore
 - OrderCenter
 - ProductCenter
 - CustomerCenter

类库隔离

如采用类库隔离形式(即依照限界上下文拆分类库)，则解决方案结构如下，Gravel作为承载体，其余三个作为上下文独立出来，按照上下文的边界高于分层的边界(这种划分也更加合理)。

- Gravel.sln
 - Gravel
 - Gravel.Web
 - Gravel.Application
 - Gravel.Core
 - Gravel.EFCore
 - OrderCenter
 - Application
 - Core
 - EFCore
 - ProductCenter
 - Application
 - Core
 - EFCore
 - CustomerCenter
 - Application
 - Core
 - EFCore

对于Asp.Net Boilerplate，见到的几个Demo及博客园内一些作者，都是采用的第一种风格形式，即分层边界高于上下文的边界。而对于第二种形式，在ABP VNext的MicroserviceDemo中采用的是这种形式。并且在ABP VNext中，这种形式的变体是可以从单体切换到微服务的。

MinIO的搭建与应用

Mon, 19 Oct 2020 10:00:00 +0800

MinIO 介绍

https://docs.min.io/cn/

MinIO 安装

MinIO 的官方文档提供了相当全面的安装信息，使用 docker 安装 MinIO，不考虑 MinIO 的分布式，毕竟对外使用来讲，MinIO 更像是个黑盒子，只关心与黑盒子的上传下载操作，而不关心是单机存储还是分布式存储。

Docker 中创建并运行 MinIO

docker run -p 9800:9000 --name minioservice \
 -e "MINIO_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE" \
 -e "MINIO_SECRET_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
 -v /mnt/data:/data \
 -v /mnt/config:/root/.minio \
 minio/minio server /data

依据 MinIO Docker 快速入门，下载 MinIO 镜像并创建一个 MinIO 容器。 https://docs.min.io/cn/minio-docker-quickstart-guide.html

参数说明：

-p：对外端口可以依据使用自定义配置，对内端口保持 9000 就行，因本地使用了 portainer，占用了 9000 的对外端口，因此更换使用 9800 端口。(MinIO 文档中使用的是 9000 的)

ABP模块系统

Sun, 18 Oct 2020 10:00:00 +0800

模块系统简介

ABP 为创建模块及组织它们提供基础框架。一个模块可依赖于另一个模块。通常地，一个程序集做为一个模块。如果你的应用是多个程序集，建议为每个程序集定义一个模块。

模块的本质就是可重用性，你可以在任意的地方去调用，而且通过实现模块，你写的模块也可以给别人用。

模块定义

一个模块定义成一个继承于 AppModule 类的类。假设我们正在开发一个能用于不同应用的 Blog 模块，最简单的模块定义可能像如下所示：

public class MyBlogApplicationModule : AbpModule
{
    public override void Initialize()
    {
 IocManager.RegisterAssemblyByConvention(
Assembly.GetExecutingAssembly());
    }
}

模块定义类负责把自己的类注册到依赖注入里（约定做法如上所示）、配置应用和其它模块、为应用添加新的特性等…

生命周期方法

ABP 在应用启动和关闭时，为模块调用一些特定的方法。你可以重写这些方法来执行一些特定的任务。

ABP 按依赖关系顺序调用这些方法。如果模块 A 依赖于模块 B，模块 B 会在模块 A 前初始化，确切的启动方法顺序是：预初始化 B，预初始化 A，初始化 B，提交 B 和提交 A。这就是依赖路线。Shutdown 方法类似，不过顺序是相反的。

PreInitialize（预初始化）

应用启动时最先调用这个方法，它通常在初始化前将模块内的配置信息添加到框架或是处理其它模块所需执行的操作。

也可以在这里写一些特定的代码运行在依赖注入注册之前。例如，你想创建一个约定注册(Conventional Registration)类，你应该在这里使用 IocManager.AddConventionalRegisterer 方法来注册这个类。

Initialize（初始化）

依赖注入注册一般都在这里完成，一般都使用 IocManager.RegisterAssemblyByConvention 方法。如果想自定义依赖注册，可以依照 ABP 提供的其他方式完成注册(手动注册)，如使用 IocManager.Register 方法直接注册或是Castle Windsor 注册.

PostInitialize（提交初始化）

在启动过程中最后调用这个方法，此时可以安全的解析依赖。

Shutdown（关闭）

当应用关闭时调用这个方法。

ABP Framework从单体切换到微服务

Sat, 26 Sep 2020 10:00:00 +0800

注：此处的微服务只考虑服务部分，不考虑内外层网关、认证等。

ABP VNext从单体切换到微服务，提供了相当大的便利性，对于各模块内部不要做任何调整，仅需要调整承载体即可。

ABP can help you in that point by offerring a microservice-compatible, strict module architecture where your module is splitted into multiple layers/projects and developed in its own VS solution completely isolated and independent from other modules. Such a developed module is a natural microservice yet it can be easily plugged-in a monolithic application.

分层架构

ABP VNext自身提供的分层方式如下图，核心部分是Application、Domain与EntityFrameworkCore层，至于HttpApi.Client与HttpApi都是属于将应用去承载到其他系统之上的。

Controller层在ABP VNext中被削弱了，VNext提供了将Application提供动态Controller，所以可能习惯了将部分逻辑写在控制器中的会有些唐突，但理解就行。

规划层次结构

新建空文件夹，取名随意(本次取名GravelService)，用于存放整体项目。
在上一步的空文件夹内新建空白解决方案，可以用VS去生成或是按照dotnet的命令生成。

习惯上按照ABP VNext给定的微服务Demo中的格式创建三个文件夹，思路清晰。当然提供的微服务Demo还有更多文件夹，但是这次只关注这三个。

AddMvcAddMvcCoreAddControllers等区别

Sat, 05 Sep 2020 10:00:00 +0800

比较一下AddMvc、AddMvcCore、AddController等在服务配置时的区别及各自拥有的功能。

1.services.AddMvcCore()

只注册路由请求和执行控制器所必要的核心服务，确保 Pipeline 程序可运转。除非是有能力并想完全去自主DIY，一般不建议直接使用这个。

2.services.AddControllers()

除包含了 AddMvcCore() 所有功能，再加上：

Authorization
ApiExplorer
Data Annotation
Formatter Mapping
CORS

要用 Controller 但不用View，新建WebAPI时，默认采用的就是这个，使用这个时，与SwashBuckle配合时，无需再额外引入ApiExplorer,自身已经依赖。

3.services.AddRazorPages()

包含 AddMvcCore() 所有功能，再加上：

Razor Pages
Authorization
Data Annotation
Cache Tag Helper

4.services.AddControllersWithViews()

包含 AddControllers() 所有功能，再加上：

cshtml和Razor View
Cache Tag Helper

标准MVC模式，常用Razor视图，使用这个就够了

5.services.AddMvc()

包含 AddControllersWithViews() 及 AddRazorPages() 功能。包含的功能最为齐全，如果不想遗漏功能，直接使用这个就行

2020-09-05，望技术有成后能回来看见自己的脚步。

AspNetCore&Coding持续集成

Sun, 09 Aug 2020 10:00:00 +0800

对于现有很多持续集成工具来讲，功能越来越高级，使用了 Coding 有大半年时间，越发觉好用，特别是没钱续费服务器时，找到了新的羊毛。

众多持续集成工具

现在可用的持续集成工具繁多，各大云服务商都推出了持续集成，甚至是一定条件内都是免费使用。比如 Azure 提供每个月 1800 分钟的免费时长，支持单项目并行构建，GitHub的GitHubActions，华为云的 DevCloud，阿里云的云效，腾讯云与 Coding 合作的Coding.DevOps 等等。在此推荐一波 Coding： https://coding.net/

对于个人开发者而言，能够薅到羊毛，是最为实在的。最近，自己买的的两台羊毛机将到期，没钱续费，并且看到各大云服务商的提供的各种福利，干脆放弃自己搭建持续集成服务。特别是半年前开始接触到 Coding，看到其中许多 Azure 的影子，并且上手后发现很好用(关键是免费)，当时只是想要提供的制品库功能用来保存 Docker 镜像(源于 TencentHub 服务的关闭)。

Coding提供5人以下免费，每周200次持续集成次数，每次限时30分钟，并行任务数1个。

Coding 的使用

注册团队账号，填写团队域名，5 人以下团队免费。

建立项目，选择模板，提供了各种场景下需要的模板，都是在完整模板上依据功能精简的，不管选择哪个模板，都可以通过功能开关获取到所有功能。

选择第二个项目模板，等会更改功能开关获取其他功能。填写项目名称，如 StarCity.Standard。

配置功能开关，开放更多功能。左下角选择并点击项目设置，跳转到设置页面中。

选择功能开关 Tab，开放更多功能，这些操作和 Azure 中的操作都是差不多的。本次只选择持续集成和制品库，其他关闭。

项目搭建及基础配置

首先在代码仓库中新建项目，对于代码仓库的选择随意，我更倾向于使用 Gitee，当然也可直接使用 Coding 提供的代码仓库。此处新建了一个仓库方便对照： StarCity.Standard
新建 AspNetCore 并增加 Dockerfile，整理成常用的目录形式。增加 gitignore、Dockerfile。

注意：此处 Dockerfile 中我使用腾讯云 Hub 中的一个源，方便构建镜像。

新建制品库，用来保存持续集成后我们需要的目标产物。依据具体用途选择仓库及权限范围。

开始配置持续集成，点击构建计划，新建计划配置，开始进行持续集成基础配置工作。

选择持续集成模板，Coding 提供了十几种模板类型，但是没得 AspNetCore 的模板，选择自定义模板，进行配置，当然，已有的这些模板可以点进去看看，学习其中的配置方式。

配置自定义模板，选择 Gitee 中的代码仓库，注意需要按照提示配置 OAuth，此处主要是依赖 Jenkinsfile 的完成持续集成功能。通过在 Coding 中配置 Jenkinsfile 减少对项目内的倾入(我个人更喜欢这种方式)。

初探Redis-基础类型SortedSet

Sun, 05 Jul 2020 10:00:00 +0800

Redis存在五种基础类型：字符串(String)、列表(List)、哈希(Hash)、集合(Set)、有序集合(Sorted Set)。本次列举出Sorted Set的常用操作。

Redis官网：https://redis.io/

有序集合(SortedSet)介绍

Redis 有序集合和集合一样也是string类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个float类型的分数(score)。通过分数来为集合中的成员进行从小到大的排序。有序集合的成员是唯一的,但分数(score)可以重复。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。

有序集合(SortedSet)相关操作Api

添加值

删除值

删除key下指定索引范围内的值

删除key下指定字典区间范围内的值

删除key下指定分数范围内的值

获取key下值的总数量

获取key下指定分数范围内值的总数量

获取key下指定字典范围内值的总数量

获取key下索引范围内的值

获取key下指定分数范围内的值

获取key下指定字典区间范围内的值

返回值相应索引

返回值相应分数

增加分数

有序集合(SortedSet)间相关操作Api

多个key做并集并存储在新key中

多个key做交集并存储在新key中

迭代获取集合中匹配的数据

有序集合(SortedSet)简单应用场景

简单模拟排行榜场景，对于蜀国贡献值排行高低，有蜀国成员负责实时生成贡献值，通过查看蜀国贡献排行榜可以实时获取排行情况。

启用一个线程生存各成员贡献值

Task.Run(() =>
{
 while (true)
 {
 foreach (var user in UserList)
 {
 Thread.Sleep(10);
 service.SortedSetAdd("蜀国贡献值", user, new Random().Next(1, 100));
 }
 Thread.Sleep(20 * 1000);
 }
});

启用一个线程实时展示贡献值排行榜

Task.Run(() =>
{
 while (true)
 {
 Thread.Sleep(12 * 1000);
 Console.WriteLine("**********当前排行************");
 int i = 1;


 var items = service.SortedSetRangeByRankWithScores<string>("蜀国贡献值", 0, -1, true);
 foreach (var item in items)
 {
 Console.WriteLine($"第{i++}名 {item.Key} 分数{item.Value}");
 }
 }
});

效果展示，可以看到实时排行情况，结合UI呈现的话，可以做到实时榜单。

初探Redis-基础类型Set

Sun, 14 Jun 2020 10:00:00 +0800

Redis存在五种基础类型：字符串(String)、列表(List)、哈希(Hash)、集合(Set)、有序集合(Sorted Set)。本次列举出Set的常用操作。

Redis官网：https://redis.io/

集合(Set)介绍

Redis 中的集合是一个字符串类型的无序集合，即集合中不存在重复的元素。集合中最大的元素个数为 2^32 -1 个，集合内部的操作是基于哈希表实现的，一次添加、查找、删除操作的时间复杂度都为 O(1)。

集合(Set)相关操作Api

添加值

删除值

查看集合内所有值

查看集合中是否有给定值

计算集合中值总量

集合中随机获取n个数据

集合中随机移除n个值并返回

迭代获取集合中匹配的数据

集合(Set)间相关操作Api

获取多集合交集结果

获取多集合交集结果并存在新集合中

获取多集合差集结果

获取多集合差集结果并存在新集合中

获取多集合并集结果

获取多集合并集结果并存在新集合中

集合内数据移动到新集合中

集合(Set)简单应用场景

简单模拟抽奖场景，利用Set中随机获取集合中一个值来完成抽奖场景，具体场景为，年会活动，用户扫码加入抽奖活动，每个用户有独自的id，抽奖项为一等奖，抽中者不能再参与抽奖活动。

初始用户id

service.SetAdd("FirstPrize", "userId1");
service.SetAdd("FirstPrize", "userId2");
service.SetAdd("FirstPrize", "userId3");
service.SetAdd("FirstPrize", "userId4");
service.SetAdd("FirstPrize", "userId5");
service.SetAdd("FirstPrize", "userId6");

完成一轮抽奖活动，随机从参与集合中获取一个用户id。

service.SetPop<string>("FirstPrize");

效果展示一下,每轮获取一个数据，并从原有集合中删除，保证了下一次抽奖活动不会再抽中原有获奖者。

初探Redis-基础类型List

Sun, 24 May 2020 10:00:00 +0800

Redis存在五种基础类型：字符串(String)、列表(List)、哈希(Hash)、集合(Set)、有序集合(Sorted Set)。本次列举出List的常用操作。

Redis官网：https://redis.io/

列表(List)介绍

Redis列表是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或者尾部（右边）。一个列表最多可以包含 232 - 1 个元素 (4294967295, 每个列表超过40亿个元素)。可按照如下格式查看，整体为链式结构，c语言中，链表功能十分强大，通过指针取得内部存储地址，再通过内部存储地址去取得实际数据(具体怎么操作已还给老师)。可以方便的完成先进先出，先进后出等功能。

列表(List)相关操作Api

LPush添加数据

将链表看成整体，进行Lpush操作，使得新添加的元素作为起始元素。

RPush添加数据

将链表看成整体，进行Rpush操作，使得新添加的元素作为末位元素。

限定key存在执行添加数据

List中指定索引处插入数据替换原有数据

对List中匹配的数据前或后插入新数据

读取List中索引范围内已有数据

通过索引范围读取范围内的数据信息

读取List中指定索引下已有数据

获取List中数据总数

移除List前部数据

移除List尾部数据

精简List只保留索引范围内数据

移除List中指定数量的匹配数据

等待匹配数据直到获取或超时

从列表中移除并移入新列表

等待从列表中移除并移入新列表直至成功或超时

列表(List)简单应用场景

以哈希用法时的文章列表为例，网站首页分页展示文章信息，而展示前先从list中取得分页后的文章Id集合再从Hash中获取文章概要信息并展示。

初始列表数据添加一些种子数据

service.ListLeftPush("blogId", "9527");
service.ListLeftPush("blogId", "9528");
service.ListLeftPush("blogId", "9529");
service.ListLeftPush("blogId", "9530");
...

模拟增加一条数据并裁剪已有的种子数据集合使得总体数量在给定范围内。

service.ListLeftPush("blogId", "9547");
service.ListRange<string>("blogId", 0, 20);//一个list最多2的32次方-1，范围外的被移除

模拟分页获取，从Redis-List中取出等量数据并打印展示。

var page = 1;
var size = 10;
var blogIdsPagedResult = service.ListRange<string>("blogId", (page - 1) * size, page * size - 1);

运行效果，达到预想功能。

初探Redis-基础类型Hash

Wed, 13 May 2020 10:00:00 +0800

Redis存在五种基础类型：字符串(String)、列表(List)、哈希(Hash)、集合(Set)、有序集合(Sorted Set)。本次列举出Hash的常用操作。

Redis官网：https://redis.io/

哈希(Hash)介绍

哈希(Hash)是Redis 中基本的类型，一个 key 对应着一个集合，其中集合中以field-value形式组成一个字典。可以理解为一个字典中，单项值部分又是一个字典。每个哈希(Hash)可以存储2^32-1个键值对。数据序列化成json格式为{key:{field1:value1,field2:value2……fieldN:valueN}}。

内部用zipmap结构存储，以节约空间
更新方便，只需更新field对应value值即可更新。

哈希(Hash)常用Api

设置field-value

设置初次添加的field-value

获取值

批量设置值

批量获取值

获取key下集合信息

获取key下所有field

获取key下所有value

删除key下的field

哈希(Hash)不常用Api

查询key下field是否存在

递增key下field映射值(△n)

递增key下field映射值(△n 浮点数)

获取key下field数量

获取key下field映射值的长度

迭代哈希表中的键值对

数量有限，返回游标仍然是0。

哈希(Hash)简单应用场景

模拟文章概要信息的Hash存储并快速获取，场景如下，网站首页分页展示文章概要信息，定义为热区文章，如某文章更改内容，则先判定是否该文章id属于热区，如属于则更改Hash中field对应的值。

模拟文章数据，设置一堆种子

var blogOutlineInfoList = new List<BlogOutlineInfo>()
{
 new BlogOutlineInfo()
 {
 Id = "9527",
 Title = "CSharp",
 Author = "微笑刺客",
 CreateTime = DateTime.Now,
 Content = "CSharp从入门到升仙",
 CommentCount =0,
 ReadCount = 0,
 RecommendCount = 0
 },
 new BlogOutlineInfo()
 {
 Id = "9528",
 Title = "Mysql",
 Author = "微笑刺客",
 CreateTime = DateTime.Now,
 Content = "Mysql从入门到遁地",
 CommentCount =0,
 ReadCount = 0,
 RecommendCount = 0
 },
 new BlogOutlineInfo()
 {
 Id = "9529",
 Title = "Docker",
 Author = "微笑刺客",
 CreateTime = DateTime.Now,
 Content = "Docker从入门到转行",
 CommentCount =0,
 ReadCount = 0,
 RecommendCount = 0
 },
 ...
};

将种子数据加入到Redis中(缓存预热)

foreach (var blogOutlineInfo in blogOutlineInfoList)
{
 //设置Redis_key
 var blogOutlineInfoKey = $"blogOutlineInfo_{blogOutlineInfo.Id}";


 //初始化属性值
 service.HashSet(blogOutlineInfoKey, nameof(BlogOutlineInfo.Title), blogOutlineInfo.Title);
 service.HashSet(blogOutlineInfoKey, nameof(BlogOutlineInfo.Content), blogOutlineInfo.Content);
 service.HashSet(blogOutlineInfoKey, nameof(BlogOutlineInfo.Author), blogOutlineInfo.Author);
 service.HashSet(blogOutlineInfoKey, nameof(BlogOutlineInfo.CreateTime), blogOutlineInfo.CreateTime);
 service.HashSet(blogOutlineInfoKey, nameof(BlogOutlineInfo.CommentCount), blogOutlineInfo.CommentCount);
 service.HashSet(blogOutlineInfoKey, nameof(BlogOutlineInfo.ReadCount), blogOutlineInfo.ReadCount);
 service.HashSet(blogOutlineInfoKey, nameof(BlogOutlineInfo.RecommendCount), blogOutlineInfo.RecommendCount);
}

网站中对于某页需要的数据，根据当前页面，先从Redis的List中获取相关文章Id，然后再从Hash中获取文章概要信息。

初探Redis-基础类型String

Sun, 26 Apr 2020 10:00:00 +0800

Redis存在五种基础类型：字符串(String)、列表(List)、哈希(Hash)、集合(Set)、有序集合(Sorted Set)。String的出镜率算是最高的。本次列举出String的常用操作。

Redis官网：https://redis.io/

字符串(String)介绍

字符串(String)是Redis 中最基本的类型，一个 key 对应着一个 value**，**可以理解为字典类型，key-value形式。该类型二进制安全的，对应值可以存储任何数据，如图片或者序列化后的对象，对应值最大可以存储 512MB 的数据。但不是建议去最大化存储，存储数据尽量小为最佳使用。从操作出发，常用操作为这两类：

存储和操作字符串；
存储和计算int和float类型的数据。

字符串(String)常用Api

设置值

设置30秒生存时间，且必须firstkey不存在。

获取值

批量设置值与批量获取值

递增或递减值(△1)

递增或递减值(△n)

递增浮点数值(△n)

获取旧值并设置新值

字符串(Strng)不常用Api

追加值

查询key

删除key

设置剩余生存时间

设置firstkey生存时间30秒，并通过ttl查看剩余生存时间。

获取剩余生存时间

设置永久生存

获取字符串长度

覆盖指定位置开始处的字符

获取指定位置范围字符串

字符串(String)简单应用场景

模拟限量商品秒杀场景，来运用一下redis。采用多线程随机请求限量商品，并且用redis控制商品数量的减少。

采用StackExchange.Redis的Nuget包来连接和管理Redis。并封装一套Redis的操作类。

采用单例模式管理Redis的实例。

模拟多用户限量秒杀模型。通过Redis的incr和decr操作控制商品数量。

/// <summary>
/// 超卖模型
/// </summary>
public class OverSell
{
 private static bool IsGoOn = true;//秒杀活动是否结束


 public static void Run()
 {
 RedisBase.StringService.StringSet("Stock", 10);


 for (int i = 0; i < 5000; i++)
 {
 int k = i;
 Task.Run(() =>//每个线程就是一个模拟用户请求
 {
 if (IsGoOn)
 {
 var index = RedisBase.StringService.StringDecrement("Stock");//-1并且返回
 if (index >= 0)
 {
 Console.WriteLine($"{k.ToString("000")} Success，Product Index:{index}");
 //...
 }
 else
 {
 if (IsGoOn)
 {
 IsGoOn = false;
 }
 Console.WriteLine($"{k.ToString("000")} Failed，Product Index:{index}");
 }
 }
 else
 {
 Console.WriteLine($"{k.ToString("000")} Finish......");
 }
 });
 }
 }
}

运行效果，部分线程抢购到商品，部分线程同步抢购时，商品没有了返回负数，部分线程抢购时，活动已结束。

初探Redis-基础篇

Sat, 25 Apr 2020 10:00:00 +0800

作为向Web而生的Redis，现已经使用得十分广泛了。依靠其高性能、简洁设计等深受开发者们喜欢。对Redis从基础学起，抱着知其然到知其所以然的想法，先学会怎么用，再去深入了解内部运转。

Redis官网：https://redis.io/

Redis简单介绍

Redis英文全称为Remote Dictionary Server，采用C语言开发的开源，基于内存的键值存储器。常被用来作为数据库(非关系型)，缓存，消息队列等。Redis本身是单进程单线程的，单机每秒读处理11万次+，写处理8万次+，提供插入、查询、固化和集群功能。

Redis安装

Redis安装方式有多种，本着快捷，方便原则(实则为懒)，依照本地环境进行快速搭建。

本地环境为Deepin 15.11，直接采用Docker安装，操作简单且管理方便。

如本地没有安装Portainer管理工具，则可以通过命令形式拉取redis镜像。

sudo docker pull redis

再通过命令创建一个redis的容器，即可本地开始玩转redis了。

sudo docker run --name rediscontainer -d -p 6379:6379 redis

如本地有安装Portainer管理工具，则直接通过工具内完成redis的镜像下载与容器创建。

2、再通过安装面板工具方便管理Redis Server。Deepin商店自带Redis管理面板RedisPlus。依靠面板，方便监控及查询相关数据。

或通过redis-cli处理，输入以下命令，通过命令行形式操控redis。

sudo docker run -it rediscontainer redis-cli

Redis内置数据类型

Redis作为键值存储器，键的类型只允许为字符串。值的类型有五种基础类型：字符串(String)、列表(List)、哈希(Hash)、集合(Set)、有序集合(Sorted Set)，还有一些高级类型如bitmap、布隆过滤器、stream等。

Redis应用场景

缓存热点数据
实时排行版
消息队列
分布式锁
数据缓存
限量控制，计数器等
任务队列
过滤器、条件排序等
……

应用场景十分丰富，对Redis的掌握也逐渐成为后端工程师必备技能之一了。

2020-04-25，望技术有成后能回来看见自己的脚步。

ABP框架开发-版本管理

Sun, 12 Apr 2020 10:00:00 +0800

多租户系统中，针对于不同租户开放不同功能，或是按照不同功能进行收费管理，需要从宿主本身去管理租户的版本信息，如同酒店人员对不同房间收取不同费用，依据房间内部设施，房间大小等设置不同收费标准。Abp系统中默认是多租户的，并且在Zero模块中实现了版本管理功能。

设计前提

基于Abp进行了相关限制，我将多租户变成了单租户，不允许添加新的租户，由于日常接触中，发现除了云平台这种SaaS需要多租户，对于企业客户来讲，自备物理服务器或自购云服务器是常有的事情，因此对于该部分客户而言，多租户也就没有太多意义，但是从软件公司本身考虑，一套软件能够销售多家客户，能够通过简单配置，开放关闭某些功能，以此来适应客户功能需求，是最佳选项了。因此对于这两种情况考虑后，对于本系统而言，采用的是单租户+宿主形式的，企业客户使用单租户，宿主形式留给软件公司方便配置单租户实际需要的功能。

在Zero中，已经默认实现了版本管理，但是对于非收费版本的页面管理，应用服务等没有具体代码实现。

版本管理

应用层增加版本应用服务，对于版本需要进行的用户操作归纳为三个。

可查看现有版本列表；
可对现有版本信息及版本拥有的功能项进行编辑更改；
可增加或是删除版本；

/// <summary>
/// 版本管理应用服务接口
/// </summary>
public interface IEditionAppService : IApplicationService
{
 /// <summary>
 /// 获取全部版本列表
 /// </summary>
 /// <returns></returns>
 Task<ListResultDto<EditionListDto>> GetEditionsList();


 /// <summary>
 /// 获取版本用于编辑
 /// </summary>
 /// <param name="input"></param>
 /// <returns></returns>
 Task<GetEditionForEditOutput> GetEditionForEdit(NullableIdDto input);


 /// <summary>
 /// 创建或更新版本
 /// </summary>
 /// <param name="input"></param>
 /// <returns></returns>
 Task CreateOrUpdateEdition(CreateOrUpdateEditionInput input);


 /// <summary>
 /// 删除版本
 /// </summary>
 /// <param name="input"></param>
 /// <returns></returns>
 Task DeleteEdition(EntityDto input);


 /// <summary>
 /// 租户更换版本
 /// </summary>
 /// <param name="input"></param>
 /// <returns></returns>
 Task MoveTenantsToAnotherEdition(MoveTenantsToAnotherEditionDto input);
}

实现应用服务

实现版本应用服务接口，以创建版本为例，顶部权限验证，增加版本信息，并且设置该版本所拥有的功能项，对于版本领域服务，Zero模块提供了完整实现AbpEditionManager，只需调用即可。

UML图例之时序图

Fri, 20 Mar 2020 10:00:00 +0800

利用时序图显示对象之间交互，通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作，用来表示用例中的行为顺序。

时序图特点

描述用例的具体细节。
对复杂的调用、函数和操作的逻辑关系进行建模。
表明对象、组件之间是如何交互的。
理解旧代码，规划新场景。

基本元素

角色(Actor)、对象(Object)、生命线(Lifeline)、控制焦点(Activation)、消息(Message)、自关联消息、组合片段。前6种较为常用，也更为重要。

角色

系统角色，可以是人、及其甚至其他的系统或者子系统。

对象

整个交互过程中的实体，可以是一个具体的类也可以是另外一个系统。对象可以用下面的图表示：

对象包括三种命名方式：

对象名和类名；
只显示类名不显示对象名，匿名类；
只显示对象名不显示类名；

生命线

时序图中每个对象和底部中心都有一条垂直的虚线，这就是对象的生命线(对象的时间线)。以一条垂直的虚线表示。

控制焦点

控制焦点代表时序图中在对象时间线上某段时期执行的操作，表示该操作的有效时长。以一个很窄的矩形表示。

消息

表示对象间相互发送的信息。消息分为三种类型：

同步消息(Synchronous Message)：消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息的接收者放弃或者返回控制。用来表示同步的意义。以一条实线+实心箭头表示。
异步消息(Asynchronous Message)：消息发送者通过消息把信号传递给消息的接收者，然后继续自己的活动，不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。以一条实线+大于号表示。
返回消息(Return Message)：返回消息表示从过程调用返回。以小于号+虚线表示。

自关联消息

表示方法的自身调用或者对象内一个方法调用另一个方法。以一个半闭合的长方形+下方实心剪头表示。

组合片段

组合片段用来解决交互执行的条件和方式，它允许在序列图中直接表示逻辑组件，用于通过指定条件或子进程的应用区域，为任何生命线的任何部分定义特殊条件和子进程。

ref：引用其他地方定义的组合片段；
alt：在一组行为中根据特定的条件选择某个交互；
opt：表示一个可选的行为；
break：提供了和编程语言中的break类拟的机制；
par：支持交互片段的并发执行；
seq：强迫交互按照特定的顺序执行；
strict：明确定义了一组交互片段的执行顺序；
neg：用来标志不应该发生的交互；
region：标志在组合片段中先于其他交互片断发生的交互；
ignore：明确定义了交互片段不应该响应的消息；
consider：明确标志了应该被处理的消息
assert：标志了在交互片段中作为事件唯一的合法继续者的操作数；
loop：说明交互片段会被重复执行

基本例子

对接WPS在线编辑服务时，采用的时序图，依照时间顺序执行，最终获取后台服务器中文件，在前端js中在线编辑word文档。

至此，对于UML时序图的相关内容做了大概的总结，对于设计时序图还是查看其他系统、对接其他系统时，提供的时序图，知道如何识别，如何设计。

2020-03-20，望技术有成后能回来看见自己的脚步。

UML图例之状态图

Thu, 06 Feb 2020 10:00:00 +0800

利用状态图模拟响应系统，反应系统模型声明周期，将静态的业务可以动态流动起来，按照预定的状态进行业务描述。

基本概念

状态(state)是指在对象的生命期中的某个条件或状况，在此期间对象将满足某些条件、执行某些活动或等待某些事件。所有对象都具有状态，状态是对象执行了一系列活动的结果，当某个事件发生后，对象的状态发生变化。
状态图(statechart diagram)用来描述一个特定的对象所有可能的状态,以及由于各种事件的发生而引起的状态之间的转移和变化。并不是所有的类都需要画状态图，有明确意义的状态，在不同状态下行为有所不同的类才需要画状态图。
状态机是计算机科学理论的一部分，但UML中的状态机模型主要是基于David Harel所做的扩展，是用来展示状态与状态之间转换的图。

基本元素

状态的组成部分

状态名(name)
进入／退出动作(entry／exit action)
内部转换(internal transition)
子状态(substate)
延迟事件(defferred event)

状态图的要素

**椭圆或圆角矩形：**表示对象的一种状态，椭圆内部填写状态名
**箭头：**表示从箭头出发的状态可以转换到箭头指向的状态
**事件：**引起状态转换的原因。事件名可在箭头线上方标出
**条件：**事件名后加方括号，括号内写状态转换条件
**动作：**转换激活时的操作
**实心圆：**初始状态
**内部实心的同心圆：**最终状态

状态的类型

①按状态过程分：

一个状态图只能有一个初态，但终态可以有一个或多个，也可以没有终态。

中间状态包括两个区域：名字域和内部转移域，如图所示。其中内部转移域是可选的。

**entry/turnOn：**当转入该状态时，做开灯动作。
**do/blinkFivetimes：**当处于该状态时，灯闪烁5次。do活动是只在状态内出现的活动，不能附加到转换上。
**event poweroff/powerSupplySelf：**当电源关闭事件发生时，用自备电源。
**exit/turnOff：**当转出该状态时，做关灯动作。
**event selfTest/defer：**当selfTest事件发生时，对象将延迟响应，到别的状态中再处理，用defer这个特定动作表示延迟。

②含有子状态的状态被称为组合或嵌套状态

组合状态可以使用“与”关系分解为并发子状态，或者通过“或”关系分解为互相排斥的顺序子状态。

**顺序子状态:**如果一个组成状态的子状态对应的对象在其生命期内的任何时刻都只能处于一个子状态，即多个子状态之间是互斥的，不能同时存在，这种子状态称为顺序子状态。

**并发子状态:**有时组合状态有两个或者多个并发的子状态机，此时称组成状态的子状态为并发子状态。

③历史状态是伪状态, 其目的是记住从组合状态中退出时所处的子状态, 当再次进入组合状态时, 可以直接进入这个子状态, 而不是再从组合状态的初态开始。

浅(shallow)历史状态, 只记住最外层组合状态的历史。
深(deep)历史状态, 可以记住任意深度的组合状态的历史。

如下图，running状态被打断到power on状态，再转回到running状态时，希望直接进入历史状态

转换（Transition）

转换是两个状态间的一种关系，表示对象将在当前状态中执行动作，并在某个特定事件发生或某个特定的条件满足时进入后继状态。每个转换只允许有一个事件触发，一个事件只允许有一个动作。

转换的五要素：源状态、目标状态、触发事件、监护条件和动作。（触发事件：如果箭头上不带任何事件名，表示是一个自动转换，当与源状态相关的活动完成时就会自动触发）。格式：触发事件（参数）[条件]/动作

举例：与状态off相关的转换有两个，其触发事件都是turnOn，只不过其监护条件不同。如果对象收到事件turnOn，那么将判断壶中是否有水；如果[没水]，则仍然处于off状态；如果[有水]则转为on状态，并执行“烧水”动作。而与状态on相关的转换也有两个，如果“水开了”就执行turnOff，关掉开关；如果烧坏了，就进入了终态了。

转换的类型

转换类型	描述	语法
外部转换	对事件做出响应，引起状态变化或自身转换，同时引发一个特定动作，如果离开或进入状态将引发进入转换、离开转换	事件(参数)[监护条件]/动作
内部转换	对事件做出响应，并执行一个特定的活动，但并不引起状态变化或进入转换、离开转换	事件(参数)[监护条件]/动作
进入转换	当进入某一状态时，执行相应活动	entry/活动
退出转换	当离开某一状态时，执行相应活动	exit/活动

UML图例之用例图

Wed, 22 Jan 2020 10:00:00 +0800

用例图主要用来描述“用户、需求、系统功能单元”之间的关系，在需求分析阶段，常会借助用例图，从用户的角度描述系统的功能，以图形可视化的方式作为开发团队与客户的交流，同时也有助于形成统一语言。

用例图描述

用例图（Use Case Diagrame）：描述了人们希望如何使用一个系统，将相关用户、用户需要系统提供的服务以及系统需要用户提供的服务更清晰的显示出来，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。之所以说用例图至关重要，是由于用户并不关心系统的实现和内部结构，只关心产品所呈现出来的外部特征动态。而用例图恰好就是描述软件产品外部特性的视图，它从用户的角度而不是从开发者的角度来描述需求，分析产品的功能和动态行为。

基本元素

参与者(Actor)

在系统外部与系统直接交互的角色或外部系统。可通过与客户的沟通交流，确定利益相关人，进而确定参与者。

**角色：**通常是具体人承担着角色，这是最常见的参与者。
**外部系统：**如CRM系统要操作OA系统，以方便发送通知，那么针对OA系统的调用，CRM系统作为外部系统这一参与者。
**时间：**如存在定时任务操作或者类似操作等，则时间作为参与者

用例

客户通过对需求的描述(主要为功能需求)，开发团队通过用例来体现系统功能和服务，通过参与者与用例的交互，来达到客户与开发团队的目标一致。

关联关系

1）参与者与参与者间的泛化关系

比如腾讯用户，包括微信用户和QQ用户两部分，但是使用腾讯业务时，只需要是腾讯用户即可，此时，可以采用泛化关系，采用三角空心箭头作为指向。

2）参与者与用例间的关联关系

参与者与用例间是简单的关联关系，一个参与者可以有着多个用例

3）用例与用例间的泛化关系

用例之间可以存在泛化关系，比如常见的支付，可以选择微信支付、支付宝支付等等，但是这个操作就是支付。泛化关系采用三角空心箭头。

4）用例与用例间的包含关系

包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。通常可以这么理解，由基础用例向复杂用例转换的过程。但是最终被参与者直接操作的还是基础用例。包含关系的图形为虚线箭头加«include»，箭头指向复杂用例。

5）用例与用例间的扩展关系

扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。当特定条件出现时，该扩展用例的行为才会被执行。扩展关系的图形为虚线箭头加上«»，箭头指向基础用例。

简单案例

依照常见的购买操作，设计简单的用例操作，当然，实际中的用例远不止这么简单，本次只是将以上几种关系融入进来，设计简单的案例。

至此，针对UML用例图的相关内容做了大概的总结，需求分析阶段，利用用例图，来方便与客户形成统一语言，也方便活动图的设计。

2020-01-22，望技术有成后能回来看见自己的脚步。

UML图例之活动图

Tue, 21 Jan 2020 10:00:00 +0800

作为UML图例中的重要角色，活动图描述的是对象活动的顺序关系所遵循的规则，作为用例实现的描述，非常适合于和用户沟通，同时也有助于为开发提供指导。

活动图简介

活动图（activity diagram）是阐明了业务用例实现的工作流程。业务工作流程说明了业务为向所服务的业务主角提供其所需要的价值而必须完成的工作，业务用例由一系列活动组成，他们共同为业务主角生成某些工件。工作流程通常包括一个基本的工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明。是UML用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流程。

基本元素

活动图起点：活动的开始节点，实心黑色圆点，只能有一个。

活动图终点：表示整个活动的结束，圆圈加内部实心黑色圆点，可以有多个结束点。

流终点：表示子流程的结束，圆圈加内部叉。

活动状态（activity）：用于表达状态机中的非原子的运行

(1)、活动状态可以分解成其他子活动或者动作状态。

(2)、活动状态的内部活动可以用另一个活动图来表示。

(3)、和动作状态不同，活动状态可以有入口动作和出口动作，也可以有内部转移。

(4)、动作状态是活动状态的一个特例，如果某个活动状态只包括一个动作，那么它就是一个动作状态。

活动状态和动作状态的图标相同，但是活动状态可以在图标中给出入口动作和出口动作等信息。

动作状态（actions）：是指原子的不可中断的动作，并在此动作完成后通过完成转换转向另一个状态

(1)、动作状态是原子的，它是构造活动图的最小单位。

(2)、动作状态是不可中断的。

(3)、动作状态是瞬时的行为。

(4)、动作状态可以有入转换，入转换既可以是动作流，也可以是对象流。动作状态至少有一条出转换，这条转换以内部的完成为起点，与外部事件无关。

(5)、动作状态与状态图中的状态不同，它不能有入口动作和出口动作，更不能有内部转移。

(6)、在一张活动图中，动作状态允许多处出现。

动作状态约束（action constraints）：用来约束动作状态，有前置条件和后置条件之分

动作流（control flow）：动作之间的转换，用带箭头的直线表示，箭头的方向指向转入的方向，简单来讲，就是让动作状态流动起来。

对象：矩形的方框，如果一个操作执行结束之后生成了某些数据需要传递给下一个目标操作，此时需要用对象节点表示。作为动作状态的输出或是动作状态的输入。

对象流：是动作状态或活动状态与对象之间的依赖关系，表示动作使用对象或动作对对象的影响。简单来说就是对象的产生或者使用过程。

(1)、一个对象可以由多个动作操作。

(2)、一个动作输出的对象可以作为另一个动作输入的对象。

(3)、在活动图中，同一个对象可以多次出现，它的每一次出现表面该对象正处于对象生存期的不同时间点。

分支与合并：用菱形表示，它有一个转换（箭头从外指向分支符号），一个或多个离开转换（箭头从分支符号指向外）。每个离开转换都会有一个监护条件，用来表示满足什么条件的时候执行该转换.

分叉与汇合：分叉用于将动作流分为两个或多个并发运行的分支，而汇合则用于同步这些并发分支，以达到共同完成一项事务的目的，对象在运行时可能会存在两个或多个并发的控制流，为对并发的控制流建模，UML中引入了交叉与汇合的概念

分叉形式

汇合形式

泳道：将活动图中的活动划分为若干组，每一个活动只允许属于一个组，并把每一个组指定个负责这组活动的业务组织，设置一个组(业务组织)名称作为泳道的名称。利用泳道图可以很方便描述多个角色之间的协作、部门之间的协作等非常有效。泳道形式上有纵向和横向两种。

活动图、流程图、状态图的区别

活动图与流程图区别

(1)、流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理过程之间有严格的顺序和时间关系。而活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程，但活动图在本质上是一种流程图。

(2)、活动图能够表示并发活动的情形，而流程图不行。

(3)、活动图是面向对象的，而流程图是面向过程的。

活动图与状态图区别

(1)、描述对象不同，状态图是描述某一对象的状态转化的，它主要是展示的是对象的状态，描述的是一个对象的事情。利用状态图我们可以看出，对象在接受了事件刺激后，会做出什么样的反应。

(2)、使用场合不同，状态图描述对象在生命期中的自身状态变化，描述用例中的业务流程变化。

简单案例

结合业务中一个添加报价单的用例，设计活动图，泳道中的业务组织分为业务员和应用系统。业务员填写一份报价单并提交,应用系统执行参数判定，如参数均正确则开始处理计算报价单价格并发送消息通知给相关人员,如不正确，则提示给业务人员修改报价单。

至此，针对UML活动图的相关内容做了大概的总结，结合开发中的场景，先规划好用例，再针对具体用例设计活动图，方便开发过程。

2020-01-21，望技术有成后能回来看见自己的脚步。

UML图例之类图

Sun, 19 Jan 2020 10:00:00 +0800

前言

作为UML图例中的重要角色，通过许多（静态）说明性的模型元素（例如类、包和它们之间的关系，这些元素和它们的内容互相连接）描述系统静态结构，帮助我们快速了解、理清系统中对象之间的关系。

类图中的几种关系

泛化关系

在代码中体现为继承关系，设计上用空心箭头实线表示。

实现关系

在代码中体现在接口和实现关系，设计上用空心箭头虚线表示。

关联关系

在代码中体现为两个类之间存在语义上的关系，体现在类之间存在的隐约关系。

单向关联：学生可以拥有书籍，学生知道书籍的存在，但是书籍无需知道学生的存在，学生可以拥有多本书籍，因此从学生指向书籍关联。设计上用箭头实线表示。

双向关联：学生知道老师的存在，老师知道学生的存在。设计上用实线表示。

关联关系常用于数据库表的设计，与数据库范式相对应。

聚合关系

特殊的关联关系，体现整体和部分的关系，设计上用空心菱形实线箭头表示。

部门不存在，员工仍然可以存在，员工离职，部门仍然存在。体现的是0和n，整体和部分，整体不存在，部分仍然可以存在。

组合关系

特殊的关联关系，和聚合关系类似，体现整体与部分关系，设计上用实心菱形实现箭头表示。

公司和部门关系体现在公司不存在，则部门也不存在了，前者掌握整体的生命周期。体现在0和0、1和n，整体不存在，则部分不存在，整体存在，则部分存在。

依赖关系

没有直接的关系，仅仅在代码运行期间，产生的依赖，如将A类中间的时间属性赋值到B类中的时间属性。A类中调用类中类型为B类的属性，A类中调用的方法，需要用到B类的信息等。设计上用箭头虚线表示。箭头指向方为被调用方。

UML类图与数据表

类图到表结构的映射中只需考虑泛化、关联关系。

1、泛化关系

父类和子类映射为表，结构简单，更改方便，但数据分散，子类众多情况下，表数量也众多。
只将子类映射为表，数据集中，方便查询，但如果父类字段扩充，需要修改子类下所有的表。
只将父类映射为表，表的数量少，读写方便，但列数量增多，所有子类的列都在父类表中存在，一行数据中，关注的信息量变少，空闲列增加。

2、关联关系

一对一关联关系，相关两个类分别映射成两张表，尽管两张表权重一样，但是实际上还是会区分成主从表形式，从表保存主表主键，需查询从表数据时，以主表id为参数，用的较少，除非从表是使用率较低的信息存储，否则会合并成一张表。
一对多关联关系，与一对一关联关系设计方式一样，设计主从表，从表保存主表主键，连表查询时，采用主键Id连从表外键查询。
多对多关联关系，设计时，采用中间表形式，多对多拆分成两个一对多，中间表负责存储两个主表主键及中间表可能拥有的自身属性。

针对于UML类图部分知识进行了一次整理，方便类图设计时，关系设计的选择。

2020-01-19，望技术有成后能回来看见自己的脚步。

Deepin安装NodeJS和NPM

Sun, 12 Jan 2020 10:00:00 +0800

NodeJS使用范围越来越广，从想尝试看看typescript怎么用到electron想玩一玩，看个前后端分离的项目前端模块都还得用到NodeJS。因此，特意去百度一波安装教程，可是没找到几个可以一次点亮的，特此记录下本次点亮之旅。

系统环境：Deepin v15.11

官网下载安装包

百度搜索NodeJS,选择Linux版本，安装方式有两种，一种是源码下载去安装，一种是编译后的文件下载安装，此处采用下载文件形式。

解压下载的安装包

可以采用右键形式解压到指定常用文件夹即可，或是采用命令形式解压，此处采用右键形式解压，本次直接解压到当前路径下。

为NodeJS添加软链接

添加软链接方式：ln -s 源文件目标文件

我本地存放的NodeJS解压后的地址 /media/yangyong/0A6A590D6A58F743/node-v12.14.1-linux-x64，看实际文件夹位置而更改

sudo ln -s /media/yangyong/0A6A590D6A58F743/node-v12.14.1-linux-x64/bin/node /usr/local/bin/node
sudo ln -s /media/yangyong/0A6A590D6A58F743/node-v12.14.1-linux-x64/bin/npm /usr/local/bin/npm


sudo chmod -R 777 /usr/local/bin/node
sudo chmod -R 777 /usr/local/bin/npm

执行完毕后用node -v、npm -v查看当前版本信息，以确定是否安装成功。

至此，安装NodeJS和NPM便可正常使用了，开始玩转前端的一些技术。

2020-01-12，望技术有成后能回来看见自己的脚步。

ABP框架开发-租户管理

Sat, 11 Jan 2020 10:00:00 +0800

软件即服务概念的推动，定制化到通用化的发展，用一套代码完成适应不同企业的需求，利用多租户技术可以去做到这一点。ABP里提供了多租户这一概念并且也在Zero模块中实现了这一概念。

多租户的概念

单部署-单数据库

部署应用程序的单个实例和单个数据库。在每个数据表（关系型数据库）里用一个TenantId（租户Id或类似的如企业Id）字段来隔离区分每个租户数据。

单部署-多数据库

部署应用的单一实例，用一个主（宿主）数据库存储租户元数据（像租户名和子域），并为每个租户建立并维护一个隔离的数据库。操作上通过识别当前租户并从主数据库中读取相对应的存储数据库地址，切换到该租户独有的数据库中执行操作。

多部署-多数据库

为每个租户部署应用的一个实例并使用一个独立的数据库，那么我们就可以在一台服务器上为多个租户服务，只需确保相同应用的多个实例在一个服务器的环境下不会互相冲突就行。

还有两种多租户形式，诸如单部署-混搭数据库、集群部署-单/多/混搭数据库，不再提及，ABP针对于这五种多租户形式都可以使用。

宿主与租户

对于这两个概念，最好的理解方式便是酒店，酒店老板即是宿主，租户只拥有房间权限，酒店老板可以提供管理所有租户和房间。

ABP中多租户配置

启用/禁用多租户

如果不需要多租户，比如说没有多租户情形，应用部署在企业私有服务器上，那么也可以不考虑多租户的使用，可以在ABP中关闭多租户(尽管关闭了，但默认还是会使用一个租户，默认租户Id为1，此时只有这个默认租户没有宿主)。在WebCoreModule中PreInitialize方法内可以添加如下代码启用或关闭多租户，默认是启用的。

public override void PreInitialize()
{
　　 ...


 Configuration.MultiTenancy.IsEnabled = true;


 ...
}

侦测当前租户并在Session中获取租户

ABP中租户名称是唯一的，对于识别当前租户或是宿主身份，ABP没有使用Asp.Net 提供的Session，声明了IAbpSession接口并提供了默认的实现(ClaimAbpSession)去测定当前租户信息，按照如下思路去确定租户。

如果当前用户登录了系统，那么可以从当前用户的声明信息中读取到当前租户信息，如果没有读取到租户信息，那么可以断定是宿主。
如果当前用户没有登录系统，那么会有几种方式去获取,如果以下几种方式仍未获取到租户Id，则认为是使用宿主登录。
从当前域名或是子域名去获取域名名称，然后通过租户仓储去查询是否存在相关的域名或子域名存在则可以确定租户Id。
从Http请求头中获取在ABP中默认配置项Abp.TenantId(该配置项可更换名称)。
从Http请求的cookie中获取Abp.TenantId

IAbpSession声明了获取当前用户和租户信息的方法，该方法允许我们获取当前登录的用户及当前的租户信息。并且获取到的信息按照不同的规则，有着不同的作用。

如果获取到的用户和租户Id都是空的，那么意味着当前用户没有登录系统，因此也无法断定出当前是宿主还是租户。
如果用户Id是空的，但是租户Id不是空的，那么可以知道是哪个租户，但是用户仍然是没有登录的，只是选择了租户。
如果用户Id不是空的，但是租户Id是空的，那么可以知道是用户使用宿主登录了系统。
如果用户Id且租户Id不是空的，那么就知道是选择了租户并且是租户中的某个用户登录了系统。

数据过滤

如果使用了多租户，那么在读取数据时，会依据当前租户Id加上额外的过滤条件，这一点ABP已经处理好了，我们无需在linq中敲代码，但是有个前提条件是，读取数据的这个实体有设置多租户。

如果实体使用的是IMustHaveTenant接口，那么读取时会依照当前租户Id进行条件过滤。
如果实体使用的是IMayHaveTenant接口，那么读取到的数据会依照当前租户Id的有无值进行区分，如果当前租户Id为空，那么将读取到宿主的数据，如果租户Id不为空，则读取相应租户数据。
如果实体没使用这两个接口，则读取到的数据不区分宿主和租户。

这两个接口使用场景：如果是宿主和租户都需要的，比如角色、用户、部门等，那么使用IMayHaveTenant接口，如果仅是租户所需要的那只需使用IMustHaveTenant接口。

宿主与租户间切换

此处切换可以这么理解，给我一个其它租户Id，我可以在我的租户中获取到其它租户的数据，相应的，其它租户也可以获取到我租户的数据，或是宿主获取租户数据。如果不给定租户Id,租户可以获取宿主数据。

public class ProductService : ITransientDependency
{
 private readonly IRepository<Product> _productRepository;
 private readonly IUnitOfWorkManager _unitOfWorkManager;


 public ProductService(IRepository<Product> productRepository, IUnitOfWorkManager unitOfWorkManager)
 {
 _productRepository = productRepository;
 _unitOfWorkManager = unitOfWorkManager;
 }


 [UnitOfWork]
 public virtual List<Product> GetProducts(int tenantId)
 {
 using (_unitOfWorkManager.Current.SetTenantId(tenantId))
 {
 return _productRepository.GetAllList();
 }
 }
}

配置一个多租户实体

基于之前的数据字典进行改造，以便适用于多个租户使用，并且考虑到宿主无需使用数据字典，将其继承IMustHaveTenant接口后，更新数据库便可。

ABP框架开发-代码生成器

Wed, 01 Jan 2020 10:00:00 +0800

在日常开发中，有时会遇到一些相似的代码，甚至是只要CV一次，改几个名称，就可以实现功能了，而且总归起来，都可以由一些公用的页面更改而来，因此，结合我日常开发中使用到的页面，封装一个适合自己的代码生成器，仅处于入门阶段，包括生成的代码结构都仅是把框架展示出来，内部详细暂时没得，针对于应用服务中的接口和实现，相关Dto，MVC中的控制器、视图及视图模型进行了模板制作及生成相关的文件。

设计思路

方案一：开始想到的是，搞个控制台，然后给一个.cs文件，然后控制台去解析其中的命名空间，类名，属性，再用配置好的razor模板去替换，再生成相关的一些文件出来，但是发现，万事开头难，第一步去解析cs文件就不好搞，找了网上的资料，不太好弄，干脆想了下，放弃这种方案，因为想到了另一种常用的方案。

方案二：直接在控制台中，配置控制台去访问数据库，然后给定指定表名，去读取数据库中的表和字段，再反过来去生成相关文件，但是这里会遇到一个这样的问题，比如我使用的是mysql，mysql本身有个配置表名大小写忽视的，这样一来，获取到的表名都将是小写打头，尽管可能配置了是区分大小写，但是，我设计表时，采用Pre_table，形式区分业务表，比如是CRM模块需要用到的CRM_Client，那将用CRM打头，后面这部分Client才是实际代码中的类名，种种问题都有可能，但是作为没有那么多可能性下，比如没得前缀，不区分大小写，形式简单，那么可以考虑使用。此时，想到了abp中的Migrator控制台并想到了方案三。

方案三：如果说直接搞一个控制台在代码中，模仿Abp自带的Migrator一样，启动后，给定类名，通过反射去取得该类的属性名，岂不是美滋滋，需要哪个类的相关文件，只需启动，然后输入类名，即可得到相关的文件。这几种方案的前提都是在Dto文件中会展示所有实体字段，如果需要选择性的使用字段，则还需借助人工智能，以人力去完成更改生成的文件。

Razor引擎的使用

我选择了方案二作为入手去实现，并且采用Razor引擎作为模板解析的工具。Nuget引入RazorEngine.NetCore包，开始实现依靠模板生成代码。

先尝试下Razor引擎，控制台中CV下Razor引擎提供的Demo，引入相关命名空间，学习下如何去使用。

string template = "Hello @Model.Name, welcome to RazorEngine!";
var result = Engine.Razor.RunCompile(template, "templateKey", null, new { Name = "World" });
Console.WriteLine(result);

运行完毕，可以获取到运行结果，需要注意的是，如果是在linux或是mac跑会得到错误，该问题是Razor引擎本身的问题，暂时只能在window下跑。

熟悉了下Razor的使用方式后，开始使用简单文件形式填充一些数据模拟生成过程。

首先，一个文件作为填充模板，一个文件内存储Json数据作为数据源，程序启动时加载两个文件。

var templatePage = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "SimpleCOders\\Templates", "templatePage.txt");
TemplatePage = File.ReadAllText(templatePage);


var templatePageJson = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "SimpleCOders\\Templates", "templatePageJson.json");
TemplatePageJson = File.ReadAllText(templatePageJson);

其次，数据源整理成相应类结构，得到批量待解析数据。

var templatePageJsonList = JsonConvert.DeserializeObject<List<PageDataModel>>(TemplatePageJson);


foreach (var templatePageJson in templatePageJsonList)
{
 RazorParse(
 templatePageJson.Index ?? 1,
 templatePageJson.Date,
 templatePageJson.Index - 1,
 templatePageJson.Index + 1,
 templatePageJson.Content
 );
}

最后，设计一下解析器，将读取到的数据源，进行解析成相关的类，然后依次按照模板生成文件

DotNet Core Console&EFCore连接Mysql

Fri, 06 Dec 2019 10:00:00 +0800

在用惯了Asp.Net Core提供的基架后，反过来想一想，貌似忘记了控制台如何去连接数据库了，因此，写一篇文章来借此巩固下并以后再来回顾时，加快步骤。

新建一个.Net Core控制台，然后安装Nuget包

Microsoft.EntityFrameworkCore.Tool
Microsoft.EntityFrameworkCore.Design
Pomelo.EntityFrameworkCore.MySql
Microsoft.Extensions.Configuration.Json

添加一个文件夹Models，并增加一个实体类Company，增加该实体类一系列属性

namespace FastConnect.Tool.Models
{
 /// <summary>
 /// 公司信息
 /// </summary>
 public class Company
 {
 /// <summary>
 /// Id
 /// </summary>
 public int Id { get; set; }


 /// <summary>
 /// 公司名称
 /// </summary>
 public string Name { get; set; }


 /// <summary>
 /// 公司地址
 /// </summary>
 public string Address { get; set; }
 }
}

再增加一个配置文件appsettings.json，按照数据库具体配置去弄，比如接口，用户名密码等，并且本次想用的数据库名。需右键设置该文件的输出方式为始终复制。

{
 "ConnectionStrings": {
 "Default": "Server=xxx;Database=fastconnectdb;Port=10143;charset=utf8;uid=tester;pwd=xxx@yy;"
 }
}

增加DbContext，并继承DbContext，该父类在EFCore中，将之前建立的类加入到该DbContext中，配置这个数据库上下文需要的连接字符串，通过配置类去读取第二步骤中的配置项文件，在OnConfiguring中使用UseMysql，该方法在Pomelo的dll中并读取其中的默认连接字符串节点。

using FastConnect.Tool.Models;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Configuration;
using System.IO;


namespace FastConnect.Tool
{
 public class FastConnectDbContext : DbContext
 {
 public DbSet<Company> Companys { get; set; }


 private IConfiguration configuration;


 public FastConnectDbContext()
 {
 configuration = new ConfigurationBuilder().SetBasePath(Directory.GetCurrentDirectory()).AddJsonFile("appsettings.json").Build();
 }


 protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
 {
 optionsBuilder.UseMySql(configuration.GetConnectionString("Default"));
 }
 }
}

在程序包管理器控制台中选择该项目，必须要选择DbContext所在项目，本次DbContext所在项目为控制台本部。

并键入如下两行,如无错误，则数据库已经生成，可以查看项目文件夹中，将会多出一个文件夹和若干文件，这是记录迁移信息的。

ABP框架开发-RBAC

Sun, 17 Nov 2019 10:00:00 +0800

在业务系统需求规划过程中，通常对于诸如组织机构、用户和角色等这种基础功能，通常是将这部分功能规划到通用子域中，这也说明了，对于这部分功能来讲，是系统的基石，整个业务体系是建立于这部分基石之上的，当然，还有诸如多语言、设置管理、认证和授权等。对于这部分功能，ABP中存在这些概念，并且通过Module Zero模块完成了这些概念。

角色访问控制之RBAC

RBAC：Role Based Access Control，基于角色的访问控制，这在目前大多数软件中来讲已经算得上是普遍应用了，最常见的结构如下，结构简单，设计思路清晰。

但是也存在其它升级版的设计，诸如用户权限表、角色组、用户组的概念等，具体分类有RBAC0、RBAC1、RBAC2等，后者功能越来越强大，也越来越复杂。

RBAC0：是RBAC的核心思想。
RBAC1：是把RBAC的角色分层模型。
RBAC2：增加了RBAC的约束模型。
RBAC3：整合RBAC2 + RBAC1。

ABP中的RBAC

在Abp中，已经集成了这些概念，并在ModuleZero模块中实现了这些概念，基于IdentityServer4的ModuleZero模块完成了封装。对于我们大多数以业务为中心的开发人员来讲，不应该又去造一个轮子，而是应该开好这辆车。首先看下Abp中的RBAC模型。

在这其中权限表中记录了用户与权限，角色与权限两部分。对于权限通常指的是功能权限和数据权限两部分，一般来讲，大多指的是功能权限，这种通过角色与权限进行管理即可，如还有用户部分的功能区分，则可以再使用上用户与权限，而对于数据权限，可以利用用户与权限部分，个人用的比较少，但是，可以想象到这么一个场景，针对于一家门店内的多个店长，角色相同即相应的权限相同，但各自关心的数据来源不同，关心东部、南部等数据，而不关心西部、北部数据，因此可以在数据层面进行划分，比如设置数据来源，东南西北，对于数据来源进行权限关联，这样一来用户本身如果拥有东部数据权限，则只能看到东部数据。

权限声明及应用

在Abp中，需要首先在Core层/Authorization/PermissionNames.cs中声明权限，Abp权限部分设计原则是：先声明再使用。

/// <summary>
/// 权限命名
/// </summary>
public static class PermissionNames
{
 #region 顶级权限
 public const string Pages = "Pages";
 #endregion


 #region 基础支撑平台
 public const string Pages_Frame = "Pages.Frame";


 #region 租户管理
 public const string Pages_Frame_Tenants = "Pages.Frame.Tenants";
 #endregion


 #region 组织机构
 public const string Pages_Frame_OrganizationUnits = "Pages.Frame.OrganizationUnits";
 public const string Pages_Frame_OrganizationUnits_Create = "Pages.Frame.OrganizationUnits.Create";
 public const string Pages_Frame_OrganizationUnits_Update = "Pages.Frame.OrganizationUnits.Update";
 public const string Pages_Frame_OrganizationUnits_Delete = "Pages.Frame.OrganizationUnits.Delete";
 #endregion


 #region 用户管理
 public const string Pages_Frame_Users = "Pages.Frame.Users";
 public const string Pages_Frame_Users_Create = "Pages.Frame.Users.Create";
 public const string Pages_Frame_Users_Update = "Pages.Frame.Users.Update";
 public const string Pages_Frame_Users_Delete = "Pages.Frame.Users.Delete";
 public const string Pages_Frame_Users_ResetPassword = "Pages.Frame.Users.ResetPassword";
 #endregion


 #region 角色管理
 public const string Pages_Frame_Roles = "Pages.Roles";
 public const string Pages_Frame_Roles_Create = "Pages.Frame.Roles.Create";
 public const string Pages_Frame_Roles_Update = "Pages.Frame.Roles.Update";
 public const string Pages_Frame_Roles_Delete = "Pages.Frame.Roles.Delete";
 #endregion


}

然后在Core层/Authorization/XXXAuthorizationProvider.cs中设置具体权限，在此处设置权限时，可以根据权限设计时候的职责划分，比如如果仅仅是多租户需要这部分，那便设置权限范围为多租户即可。

DotNet轻量状态机Stateless的简单应用

Thu, 31 Oct 2019 10:00:00 +0800

对于大部分系统中流程的变更，是十分正常的事情，小到一个状态的切换，大到整个系统都是围绕业务流再走，复杂点的有工作流引擎，简单点的几个if/else收工，但是往往有那种，心有余而力不足的，比简单复杂，比复杂简单，最近，对业务流程的变更这一块一直再琢磨，没有找到一些让我豁然开朗的资料，本次只能是讲讲我的设计过程，作为反面教材去对比的，同时借鉴staleless去简化一下日常中的设计。

常用的流程变更

采用状态控制数据操作，通过操作变更状态，通过switch、if/else去区分状态，然后依据状态做出不同的指示，从一个大家十分熟悉，但又及其简单的例子着手，思路更加清晰。

对于订单的状态，一开始用几种描述的方式固定下来，代码实现中，有人喜欢枚举，有人喜欢字符串，这都无所谓了，罗马路条条。只是这个流程是相对固定的，与一些业务系统中，十几个转折或是几十个流程节点那样，那种貌似大多使用的都是工作流吧，存在变更，还要容易变更。

先定义个简单的订单类及用到的枚举值，这些信息应该是很熟悉且常见的。

public class Order
{
    public Order(long orderId, string orderName, string orderNo, double price)
    {
        OrderId = orderId;
        OrderName = orderName;
        OrderNo = orderNo;
        Price = price;
        CreateDate = DateTime.Now;
        InitOrderState();
    }


    /// <summary>
    /// 订单Id
    /// </summary>
    public long OrderId { get; set; }


    /// <summary>
    /// 订单名称
    /// </summary>
    public string OrderName { get; set; }


    /// <summary>
    /// 订单编号
    /// </summary>
    public string OrderNo { get; set; }


    /// <summary>
    /// 创建日期
    /// </summary>
    public DateTime CreateDate { get; set; }


    /// <summary>
    /// 订单价格
    /// </summary>
    public double Price { get; set; }


    /// <summary>
    /// 订单状态
    /// </summary>
    public OrderState OrderState { get; private set; }


    /// <summary>
    /// 初始订单状态
    /// </summary>
    public void InitOrderState()
    {
        OrderState = OrderState.OrderCreated;
    }


    /// <summary>
    /// 设置订单状态
    /// </summary>
    /// <param name="orderState"></param>
    public void SetOrderState(OrderState orderState)
    {
        OrderState = orderState;
    }
}

对于枚举值而言，我这貌似没太大含义，但是有些场景下可能会用的到，暂时先搞上

DotNet轻量状态机Stateless介绍

Sun, 22 Sep 2019 10:00:00 +0800

很多业务系统开发中，不可避免的会出现状态变化，通常采用的情形可能是使用工作流去完成，但是对于简单场景下，用工作流有点大财小用感觉，比如订单业务中，订单状态的变更，涉及到的状态量不是很多，即使通过简单的if-else也能足够使用，甚至是用上switch去减少if-else的使用，都是可以的，尽管这会丧失某些东西。为更好的优化整个流程，此时会考虑到使用状态模式来解决一些问题。

Stateless状态机GitHub：https://github.com/dotnet-state-machine/stateless

状态模式与状态机

状态模式"允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类 “。 (State Pattern: “Allow an object to alter its behavior when its internal state changes. The object will appear to change its class “.)

对于这个定义，有点抽象，变通理解一下可以这么理解：状态拥有者将变更行为委托给状态对象，状态拥有者本身只拥有状态(当然也可以抛弃状态对象)，状态对象履行变更职责。

状态机：“依照指定的状态流程图，根据当前执行的动作，将当前状态按照预定的条件变更到新的状态 “。

状态机有4个要素，即现态、条件、动作、次态。其中，现态和条件是“因”，动作和次态是“果”。

现态 - 是指当前对象的状态
条件 - 当一个条件满足时，当前对象会触发一个动作
动作 - 条件满足之后，执行的动作
次态 - 条件满足之后，当前对象的新状态。次态是相对现态而言的，次态一旦触发，就变成了现态

状态迁移图：“在UML建模中，常常可见，用来描述一个特定的对象所有可能的状态,以及由于各种事件的发生而引起的状态之间的转移和变化，也是配置状态机按照何种行径的前提 “。

Stateless功能介绍

Stateless是一个基于C#创建状态机的简单库。基于.Net Standard实现，在.Net Framework和.Net Core项目中都可以使用。源码地址：https://github.com/dotnet-state-machine/stateless。

以一个打电话的使用案例来讲讲Stateless的功能：

//初始化状态机
var phoneCall = new StateMachine<State, Trigger>(State.OffHook);

//流程配置
phoneCall.Configure(State.OffHook)
 .Permit(Trigger.CallDialled, State.Ringing);

phoneCall.Configure(State.Ringing)
 .Permit(Trigger.CallConnected, State.Connected);

phoneCall.Configure(State.Connected)
 .OnEntry(() => StartCallTimer())
 .OnExit(() => StopCallTimer())
 .Permit(Trigger.LeftMessage, State.OffHook)
 .Permit(Trigger.PlacedOnHold, State.OnHold);

// ...

//触发行为
phoneCall.Fire(Trigger.CallDialled);
Assert.AreEqual(State.Ringing, phoneCall.Stat

功能特性

状态机常见功能：

KnockoutJS-自定义属性绑定

Thu, 29 Aug 2019 10:00:00 +0800

在knockoutjs中，已有的绑定功能已经十分强大，基本上可以不需要再去考虑扩展了，但是，也有例外的场景，面对这种场景，还是得去完成，knockoutJS提供了自定义绑定来扩展绑定功能。

新建绑定

新建一个js文件来尝试绑定功能，按照给定的格式ko.bindingHandlers.xxx来扩展一个绑定。

ko.bindingHandlers.yourBindingName = {
 init: function(element, valueAccessor, allBindingsAccessor, viewModel) {
 // This will be called when the binding is first applied to an element
 // Set up any initial state, event handlers, etc. here
 },


 update: function(element, valueAccessor, allBindingsAccessor, viewModel) {
 // This will be called once when the binding is first applied to an element,
 // and again whenever the associated observable changes value.
 // Update the DOM element based on the supplied values here.
 }
};

其次，在html中完成绑定即可，用法同自带的绑定。

ABP框架开发-设置管理

Sun, 11 Aug 2019 10:00:00 +0800

在网站开发中，设置是不可缺少的一环，如用户设置、系统设置、甚至是租户设置等。ABP对于设置的管理已经做了很好的处理，我们可以借助巨人的力量来完成我们的冒险。

ABP官网地址：https://aspnetboilerplate.com/

设置的层级划分

ABP中提供了三种类型的设置，用户级别、应用级别、租户级别，针对于不同级别有着不同的侧重点，比如用户级别，针对于用户的一些设置，如主题设置，接收通知设置等；针对应用级别，该级别也能在用户层级上进行影响，好比如设置统一的主题皮肤，而它主要体现在整个应用程序上的一些设置，如业务开发中用到的流水号自定义等，在应用程序级别进行配置；而针对租户级别，可以为特定租户完成设置(租户级别个人暂没有涉及到)。

定义设置

先得定义设置才能使用设置，首先创建一个类并继承SettingProvider类，ABP已经在Core层创建了一个AppSettingProvider类，直接使用该类即可，如果需要在其它模块中(ABP是模块化的)定义设置，可以直接参照这个类，并且在模块中注册即可。

/// <summary>
/// 设置命名
/// </summary>
public static class AppSettingNames
{
 /// <summary>
 /// 系统管理
 /// </summary>
 public static class HostManagement
 {
 public const string CompanyName = "App.CompanyName";
 public const string CompanyAddress = "App.CompanyAddress";
 }


 public const string UiTheme = "App.UiTheme";
}

为保证后期业务上的设置不产生影响，还是先进行区分好了，建立一个系统设置来维护一些相对于用户和租户而言独立的应用层级的设置。

开始定义设置项信息，从ABP官网文档中看到有一个SettingDefinition类，用于定义设置项信息，查看该类创建时需要的参数

name：命名 (必填)，命名必须系统内唯一，建议是用常量字符串；
defaultValue：默认值(选填)，能为null或空字符串；
displayName：显示名称(选填)，UI呈现上显示的名称；
group：分组(选填)，可对同一类别的设置进行分组，用于UI上分组展示；
description: 设置项描述(选填)，UI上呈现该设置项的描述信息；
scopes：设置范围(默认是应用层级)，用于定义该设置项是用于哪一层级，该设置范围可以归属多个层级；

ABP框架开发-系统日志

Sat, 03 Aug 2019 10:00:00 +0800

网站正常运行中有时出现异常在所难免，查看系统运行日志分析问题并能够根据错误信息快速解决问题尤为重要，ABP对于系统运行日志这块已经做了很好的处理，默认采用的Log4Net已经足够满足开发过程中的需要了(当然有需要的话也可以更换为其它日志组件)。

ABP官网地址：https://aspnetboilerplate.com/

日志文件

ABP框架默认使用了Log4Net日志组件，日志记录在txt文件中，也可以替换成其它日志组件诸如Nlog，方便将日志文件信息直接记录到数据库中，具体情形使用具体组件。

当一个文件达到了在Log4Net配置中设置好的文件大小上限时，在文件名后按照数字倒排后开始继续增加文件。

当需要查看错误信息时，直接在日期最近的文件中找出错误信息即可，但是这个过程比较繁琐，还需要从日志文件中去查看，并且日志文件中虽然做了分类，哪些是正常信息，哪些是错误信息，但是不太直观，因此，可以考虑直接将日志文件在页面中呈现，对信息进一步加工，方便直接查看。

参考了AbpZero中的部分代码并根据实际需要进行整合，开始在页面中设计日志展示层。

页面展示日志信息

系统日志服务应属于整个系统中相对其他业务模块独立的一部分，因此，首先在应用层中新建一个Logging文件夹并创建一个日志应用层服务接口与其实现。在接口中声明两个方法，直接查看当前最近的日志文件中的日志信息以及从服务器下载所有的日志文件。

/// <summary>
/// 网站运行日志应用层服务
/// </summary>
public interface IWebSiteLogAppService : IApplicationService
{
 /// <summary>
 /// 获取最近的一个日志文件
 /// </summary>
 /// <returns></returns>
 GetLatestWebLogsOutput GetLatestWebLogs();


 /// <summary>
 /// 下载所有的日志文件
 /// </summary>
 /// <returns></returns>
 FileDto DownloadWebLogs();
}

首先考虑直接获取最近的日志文件信息，直接读取即可，遵循的规则是读取指定文件夹下指定文件后缀名更改日期为最大的文件然后从中读取日志信息，并返回到前端。

public GetLatestWebLogsOutput GetLatestWebLogs()
{
 var directory = new DirectoryInfo(AppConsts.LogFilePath);


 if (!directory.Exists)
 {
 return new GetLatestWebLogsOutput
 {
 LatestWebLogLines = new List<string>()
 };
 }


 var lastLogFile = directory.GetFiles("*.txt", SearchOption.AllDirectories)
 .OrderByDescending(f => f.LastWriteTime)
 .FirstOrDefault();


 if (lastLogFile == null)
 {
 return new GetLatestWebLogsOutput();
 }


 var lines = AppFileHelper.ReadLines(lastLogFile.FullName).Reverse().Take(1000).ToList();
 var logLineCount = 0;
 var lineCount = 0;


 foreach (var line in lines)
 {
 if (line.StartsWith("DEBUG") ||
 line.StartsWith("INFO") ||
 line.StartsWith("WARN") ||
 line.StartsWith("ERROR") ||
 line.StartsWith("FATAL"))
 logLineCount++;


 lineCount++;


 if (logLineCount == 100) break;
 }


 return new GetLatestWebLogsOutput
 {
 LatestWebLogLines = lines.Take(lineCount).Reverse().ToList()
 };
}

在前端处理日志信息，Mvc层中新增一个控制器，并写一个方法调用日志服务获取最近的日志文件信息，并处理好权限问题及页面左侧菜单的展示。

/// <summary>
/// 系统维护控制器
/// </summary>
[AbpMvcAuthorize]
public class MaintenanceController : SurroundControllerBase
{
 private readonly IWebSiteLogAppService _webSiteLogAppService;


 public MaintenanceController(IWebSiteLogAppService webSiteLogAppService)
 {
 _webSiteLogAppService = webSiteLogAppService;
 }


 /// <summary>
 /// 首页
 /// </summary>
 /// <returns></returns>
 public IActionResult Index()
 {
 return View();
 }


 /// <summary>
 /// 获取最近日志信息
 /// </summary>
 /// <returns></returns>
 public JsonResult GetLatestWebLogs()
 {
 var getLatestWebLogsOutput = _webSiteLogAppService.GetLatestWebLogs();
 return Json(getLatestWebLogsOutput);
 }
}

增加一个视图文件并开始编写前端代码获取日志文件，利用abp前端封装好的ajax请求快速的获取日志文件，然后通过layui中提供的徽章进行加工处理，如此一来，通过颜色快速区分哪些是错误信息，哪些信息权重更大，更值得关注，此处引用了一个lodash.js，该js中提供了许多的辅助方法。

ABP框架开发-消息通知

Sat, 27 Jul 2019 10:00:00 +0800

业务型网站使用过程中，消息通知是一个不可或缺的功能，采用站内通知、短信通知、邮件通知、微信通知等等各种方式都有，ABP框架对这部分工作已经封装的很好了，站在巨人的肩膀上，一览全貌，带来的就是心情舒畅。

ABP官网地址：https://aspnetboilerplate.com/

明确概念及设计

一次完整的消息发送/接收过程中，会存在几个必要的点，也正如同现实生活中的场景，有人发送，有人接收，发送的消息本身也有类型。

消息类型定义

在ABP中已经提供了消息类型定义的相关类，但是需要我们去实现，在领域层新建一个Notifications文件夹并添加一个定义常用消息类型名称的静态类如AppNotificationNames(名称可随意)，在其中开始定义消息类型名称。

/// <summary>
/// 设置应用程序中常用通知唯一的名称常量
/// </summary>
public static class AppNotificationNames
{
 #region 新的任务
 public const string NewTask = "App.NewTask";
 #endregion


 #region 简单消息
 public const string SimpleMessage = "App.SimpleMessage";
 #endregion
}

其次，开始消息类型定义，新建一个NotificationProvider的类，完成消息类型定义，管理消息类型时，可以针对消息设置权限，这样方便不同的角色拥有不同的消息通知。

/// <summary>
/// 消息类型定义
/// </summary>
public class AppNotificationProvider : NotificationProvider
{
 /// <summary>
 /// 设置消息类型
 /// </summary>
 /// <param name="context"></param>
 public override void SetNotifications(INotificationDefinitionContext context)
 {
 #region 任务提醒
 context.Manager.Add(
 new NotificationDefinition(
 AppNotificationNames.NewTask,
 displayName: L("NewTask"),
 permissionDependency: new SimplePermissionDependency(PermissionNames.Pages_TaskManage)
 )
 );
 #endregion
 }


 private static ILocalizableString L(string name)
 {
 return new LocalizableString(name, SurroundConsts.LocalizationSourceName);
 }
}

最后在领域层的Module.PreInitialize()中完成加入。

ABP框架开发-数据字典

Sun, 07 Jul 2019 10:00:00 +0800

在业务型的系统开发中，我们需要维护各种个样的类型，比如客户类型、客户行业、商品类型等等，这些类型往往信息量不多，并且相似度极高，如果采用一类型一表去设计，将会造成极大的工作量，通过将这部分类型的信息进行抽象，利用字段去存储类型区分，共用表结构，来达到兼容各种类型的功能，也就是设计一个数据字典，而对于一个具体类型来讲，是有多个选项的，比如性别，有男女，行业有工农商等，对于这部分选项，可抽象为某个类型下的字典项，即数据字典项。

数据字典设计思路

从客户类型、商品类型、行业类型来抽象考虑，首先三者都存在一个类型描述，即客户、商品、行业，同时，三者是本质是不同的，并且，随着业务上的需求越来越多，更多的xx类型将会加入，因此，单从类型考虑出发，就存在三个点了，如类型名称、类型独立、数量扩展，因此在考虑表结构设计时，就可以先考虑到这三点了，同时还有一个关键的信息，便是，在系统设计过程中，这些类型其实便已经确定完毕了，而不是说，在开发完毕，再去系统中增加类型。

从具体的某个类型出发考虑，比如以商品类型为例，存在日用品、电子产品、化妆品等，同样是存在几个关键信息，比如类型项名称、类型项独立、类型项数量扩展，类型项的归属，而这部分信息，往往是由客户去维护的，属于系统开发完毕后期的信息维护，在此，不考虑类型项的先后顺序问题，如有需要可以扩展。

按照这些信息点，可以对数据字典设计一些必要的字段，如类型名称即TypeName、类型独立便是类型间相互独立，但是这里也存在一个类型间的上下父子问题，暂不加入进来，该父子问题使用场景较少，但又存在，如果按照“二八原则”的话，我还是喜欢把“八”的部分完成。对于数据字典项而言，按照给定的必要信息，设计成如下结构，其中的业务代码，是需要唯一的，比如对于性别来将，业务代码便是1或0，来代表男女，这部分可由客户的系统管理员进行维护。

完成数据字典设计

在明确了这些基础信息后，开始在项目中完成设计过程，首先得明确数据字典本身的归属，数据字典是为整个业务而服务的，因此我把它划分到核心层这一级别中，首先在领域层设置Core层文件夹，用来存放为整个业务提供基础设施的功能模块。

在Core层中加入数据字典模块，结构设计如：

开始创建数据字典类，并添加设计的字段，以保证够用为前提，或许更多场景下会出现诸如父子字典情形，或是对字典内容的描述等，暂不考虑。

/// <summary>
/// 核心_数据字典
/// </summary>
[Table("Core_DataDictionary")]
public class DataDictionary : Entity<long>
{
 public const int MaxNameLength = 30;


 /// <summary>
 /// 字典类型
 /// </summary>
 [StringLength(MaxNameLength)]
 public string TypeName { get; set; }


 /// <summary>
 /// 关联数据字典项
 /// </summary>
 public virtual ICollection<DataDictionaryItem> DataDictionaryItem { get; set; }
}

在增加数据字典项类，并添加设计时的字段信息，这里我通过数据注解完成对字段的一些约束，如长度约束，表名的映射等。

数据库扩展表设计过程记录

Mon, 27 May 2019 10:00:00 +0800

这两天需要实现一个动态表单设计，面对着属性的不确定，要能够容纳不同的属性进来，之前也接触过这方面的设计，但是没有设计好，导致问题太多，这一次参考一些前辈们的经验后，再次尝试一番，通过动态设计表结构，以达到任务要求。

常用动态表结构设计方式

动态修改表，适应变化。
预留字段实现动态表结构(伪动态)。
将动态属性全部保存在一个字段中，xml或是json格式保存(版本号+通用列)。
表结构和表数据分离，xml形式分别保存表结构和表数据。
横向表转纵向表(属性字段行存储)。

对于这几种方式，或许不同的选用适用不同的形式，我选择了最后一种来实现我现有的设计，这种方式个人感觉更加灵活，可以更方便的扩展属性(适合的才是最好的)。

横向表转纵向表初步设计

首先看下横向表的设计，如果采用横向表，因为业务的需要，要容纳好几种行业的信息进来，这样一来整张表的字段数将会非常多，从设计或是维护角度来讲，这都是一个棘手的芋头，因此传统的横向表设计不能满足现有的需求了。

按照横向表转纵向表的思路对表结构进行更改，通过设置成键值对形式，得到如下表结构。

在这里可能有一个情况得想清楚了，我们每一次增加一条记录的时候，记录内的信息是作为同一批添加进来的，反过来，当我从数据库中取出数据时，也应该需要把同一批的记录信息取出来，因此在上面的设计中再加入一个GroupId用来区分同一批次的数据，而至于属性的重复量很大，之后将进行优化处理。

现在看到这个结构时，对于动态扩充属性来讲，已经是达到了我的预期了，对于数据库设计时，将检测指标及限值均设置成字符串的，分组号我采用时间戳的形式进行存储，当然也可以采用其它更为稳妥的方式，如Guid或是自定义ID等。

对于好多检测指标名称出现重复情况，我将这部分单独抽出来一张表用于存储检测指标属性，需要注意的是此处的名称需要在某个检测项目编号下唯一，该部分属性先在界面上呈现，其次呈现对应的数据，如果某列增加或删除了，对应展示行也就空着了一个数据或是消失了一个数据单元，而对于改了指标名称或是对外的展示名称，都不会影响数据的存储，通过默认值可以使得有些常用值不要再二次输入，减少工作量。

在具体检测限值中完成对检测指标的关联，加入一列完成外键关联，同时对原有表内存在的列可以进行优化，因为这些信息都在检测指标中存在了，不必要的数据冗余还是不存在为好。单从现在的表结构来看，当我们按照在增加一些额外的属性时，可以做到不要去修改表结构，而只需要对表内数据进行管理即可。

代码实现过程

此处我采用Asp.Net Core MVC并利用Razor语法，更为方便的完成表单展示工作，当然对于这部分工作，采用js或模板等等都是可以快速完成的。

首先对于界面添加检测指标的设计，遵循普通的表单设计方式即可，此处增加了两个隐藏元素，为适用于编辑场景而存在，此处快速略过提交到后台并保存到数据库的过程，可能需要在后台验证提交的名称的唯一性。

<div class="layui-fluid">
 <form class="layui-form" lay-filter="layuiadmin-form-evaluationIndex" style="padding: 15px 0 0 0;">
 <input type="hidden" name="id" value="@Model.Id" />
 <input type="hidden" name="evaluationStandardId" value="@Model.EvaluationStandardId" />
 <div class="layui-form-item">
 <label class="layui-form-label">名称</label>
 <div class="layui-input-block">
 <input type="text" name="name" lay-verify="required" placeholder="请输入名称" autocomplete="off" class="layui-input">
 </div>
 </div>
 <div class="layui-form-item">
 <label class="layui-form-label">显示名称</label>
 <div class="layui-input-block">
 <input type="text" name="displayName" lay-verify="required" placeholder="请输入显示名称" autocomplete="off" class="layui-input">
 </div>
 </div>
 <div class="layui-form-item">
 <label class="layui-form-label">默认值</label>
 <div class="layui-input-block">
 <input type="text" name="defaultValue" placeholder="请输入默认值" autocomplete="off" class="layui-input">
 </div>
 </div>
 <div class="layui-form-item">
 <div class="layui-input-block">
 <button class="layui-btn layui-hide" lay-submit lay-filter="LAY-evaluationIndex-front-submit" id="LAY-evaluationIndex-front-submit">立即提交</button>
 </div>
 </div>
 </form>
</div>

对于增加具体的检测记录，需要先读取到整个检测项目下的所有检测指标，然后实现生成表单的过程，按照如下的思路一步一步实现：

对于第一步，从数据库获取指定检测项目的检测指标，该步可以直接利用提供的id做一次查询即可得到相应的指标集合。然后在前端循环输出时，利用Razor语法完成动态渲染Html，生成label和input元素，依照之前设计检测指标时的name唯一，可以在此处设计表单时指定name属性。

ABP框架开发-异常信息

Sat, 27 Apr 2019 10:00:00 +0800

接触ABP框架有一段时间了，也遇到了一些问题，看了官网文档，但是或许是看的不够细致的原因，实际开发中还是遇到了一些问题，耗费了时间去处理，回头一看，原来文档中早已提及。

开发环境：ABP+MPA模式+Asp.Net Core

异常信息处理

犹如ABP官网文档所介绍的，ABP已经帮我们把异常这块处理的很完善了，我们要做的就是利用好ABP处理异常的功能。

ABP提供了直接将应用层对外服务的功能，通过ABP运行时所创建的动态API层，我们可以使用js方法去直接调用应用层服务，当然直接访问控制器下的方法并没有被舍弃。

在ABP内自动封装好了一批处理异常的类，配合着这些异常类的使用，ABP在前端也封装了一些方法，方便我们处理异常信息，同时我们也可以改造前端在展示异常的方式，ABP封装的是使用Message API展示异常信息并使用的是sweetAlert插件，ABP前端js中提供了方式可以使得我们阻止默认的展示，进而使用自定义的展示插件和展示方式。

在封装的类中，UserFriendlyException是对用户友好的，对于一些操作可能产生的问题，可以通过抛出UserFriendlyException直接展示给用户看，而对于其它异常，前端会将详细信息的隐藏，因为用户并不会关心具体报错原因，只知道是报错了。在代码中，有些操作可能需要我们进行判断，然后反馈给用户，以便提示用户更改相关数据。

[AbpAuthorize(AppPermissions.Pages_Standard_ItemCode_Create)]
private async Task CreateItemCodeAsync(CreateOrUpdateItemCodeInput input)
{
 var itemCode = ObjectMapper.Map<ItemCode>(input.ItemCode);
 itemCode.Id = itemCode.CreateUniqueItemCode();


 var existedItemCode = await _itemCodeRepository.FirstOrDefaultAsync(t => t.Id.Equals(itemCode.Id));
 if (existedItemCode != null)
 {
 throw new UserFriendlyException(L("该检测项目已经存在."));
 }


 await _itemCodeRepository.InsertAsync(itemCode);
}

如上，在做一个操作前，可能需要判断是否有相同的记录，如果有，需要提示给用户，通过直接抛出UserFriendlyException，在控制器内或在应用层抛出异常都行，可以将信息直接呈现给用户，但是需要注意的是有一些条件限制，需要满足相关的条件才能获取到该错误信息，否则很有可能拿到如下结果或是英文错误：“An error has occurred! Error detail not sent by server.”

展示异常信息的方式

在ABP文档中，专门有一篇文章是处理异常的，https://aspnetboilerplate.com/Pages/Documents/Handling-Exceptions。

AspNet Core&钉钉开发系列

Thu, 18 Apr 2019 10:00:00 +0800

阿里钉钉在商业领域的规模越来越大，基于钉钉办公的企业越来越多，将一个企业内现有用到的工具(如钉钉)能够更融入到他们的工作中，提高工作效率，那便需要开发者不断的学习、应用了，同时，个人也有一个预感，未来围绕钉钉作为企业办公的必备利器，将会减少我们在软件开发过程中一些基础设施的建设，如部门、用户等这些的管理，更加偏重业务的价值了。

接入钉钉初衷

钉钉内部的一些功能越来越丰富，如果结合到现有业务功能中，可以减少部分功能的再次开发，而是直接利用钉钉完成，比如，新上线的一个审批签名功能，如果能够引入到现有公司业务中，便更加方便了业务员在外的一些操作。可能有人喜欢自己造轮子，或许我的观点不太一样，我更喜欢站在巨人的肩膀上，毕竟人的精力是有限的。注册一个企业账号即可接入平台，企业账号不一定是要实际的企业账号(作为程序员来讲，创业也是一个梦想，直接用心仪的创业公司名称来练手那肯定是不错的了)。

钉钉开发平台地址：https://open.dingtalk.com/?spm=a3140.8736650.2231602.6.35653a1aJxWjAp&source=1001&lwfrom=2017120202091367000000111

认清需要哪种形式的服务

参考了钉钉开发文档：https://open-doc.dingtalk.com/，看完后感觉有点绕，针对一个类型来讲有多种方式，而针对多个类型，有更多方式。

因此特意汇总成一图解释，其中移动开发部分进行了过滤，对移动开发部分经验空白，不敢引入其中。

如果是直接利用钉钉开发应用然后在钉钉上面使用，那么选择快速入门中的资料即可，具体是用于企业内部，还是用于第三方企业，还是第三方个人，再看场景。

如果是在企业现有系统中去加入一些钉钉的功能，比如消息通知等等，调用钉钉服务端接口即可，我使用该部分的频率较高，可以在现有企业系统使用到钉钉内的一些功能，但不需要完全接入到钉钉中。

如果是使用前端通过JS调用或展示一些信息，通过前端API的形式实现即可，其中E应用需要为移动端，PC端暂不支持，H5微应用支持PC、移动端。

后期接入工作

参照企业内部应用中服务端Api接入方式，将现有Asp.Net Core应用程序与钉钉完成一系列交互工作，利用钉钉提供的一些功能，在此基础上尝试一些能够促进工作效率的功能。

系列文章

Asp.Net Core对接钉钉群机器人

2019-04-18，望技术有成后能回来看见自己的脚步。

AspNet Core&Jenkins持续交付到Windows Server

Thu, 21 Mar 2019 10:00:00 +0800

对于Linux平台上的持续集成和持续交付可以使用Docker快捷的完成任务，但是Windows Server下却不好使用，一般来讲，windows Server下最简单的发布方式是直接手动打包发布或是利用webDeploy完成，但是手动发布太麻烦，webDeploy配置也麻烦，因此尝试使用Jenkins+Powershell，将代码拉取到Windows Server上然后通过dotnet命令发布，并通过Powershell更新相应的网站，但是首次网站配置工作，还是得手动进行发布工作，对于在公司内部服务器测试来讲，可以减轻许多工作量，做到代码合并到主干即可更新测试服务器。

本地环境及工具：Windows Server 2008R2+Jenkins+Powershell+.Net Core2.2

服务器安装Jenkins

从Jenkins官网下载Windows下的Jenkins程序,下载的压缩包解压后为msi版本，作为系统服务在后台运行，移入到服务器中

执行安装，按照正常的安装步骤安装即可

安装完毕会自动打开网站或手动访问localhost:8080，开始配置Jenkins，找到网站中指定的路径中，拿到生成的密码解锁Jenkins。

下一步安装推荐的插件即可,如果知道哪些插件要安装则选择另一个选项，此处我选择第一个也是默认选项，然后等待安装即可。

安装完毕，配置管理员账号密码完毕即可，完成后自动跳转到Jenkins中，下次登录时需要用刚配置好的账号密码登录。

服务器配置IIS、安装.Net Core SDK及AspNetCoreModule

配置IIS及相关需要的服务

通过图形界面配置IIS并安装需要的服务,可参考Windows ServerR2配置教程：https://jingyan.baidu.com/article/5d6edee2e034f099eadeec3c.html

或通过脚本配置IIS，打开Windows Powershell Modules工具，先通过命令查看本地的功能。

get-command -module servermanager

如我本地是Add-开头，则需要将Install-WindowsFeature更换成Add-WindowsFeature，否则稍后的操作会得到如下错误，在2008R2上是Add-开头，而在2008R2以后的版本是Install-开头，此部分可以查看微软官方文档。

再次查看IIS服务并得到展示可以选择的服务，该部分服务就是图形化界面中的选项菜单，选择好需要的服务后

get-windowsfeature web*

执行以下命令完成脚本配置IIS，可以比对脚本内的服务和powershell中的服务，直接继续按照命令安装即可，至此IIS配置及安装需要的服务完成。

$IISFeatures = "Web-WebServer","Web-Common-Http","Web-Default-Doc","Web-Dir-Browsing","Web-Http-Errors","Web-Static-Content","Web-Http-Redirect","Web-Health","Web-Http-Logging","Web-Custom-Logging","Web-Log-Libraries","Web-ODBC-Logging","Web-Request-Monitor","Web-Http-Tracing","Web-Performance","Web-Stat-Compression","Web-Security","Web-Filtering","Web-Basic-Auth","Web-Client-Auth","Web-Digest-Auth","Web-Cert-Auth","Web-IP-Security","Web-Windows-Auth","Web-App-Dev","Web-Net-Ext","Web-Asp-Net","Web-ISAPI-Ext","Web-ISAPI-Filter","Web-Mgmt-Tools","Web-Mgmt-Console"
Install-WindowsFeature -Name $IISFeatures

可能会得到如下错误信息，需要修改Powershell的执行策略。

先通过命令查看当前策略

get-executionpolicy

设置当前计算机允许执行脚本

set-executionpolicy remotesigned

再次执行配置IIS的脚本等待安装直到成功。

安装.Net Core环境

先从官网下载.Net Core SDK和用于与IIS打交道的Runtime & Hosting Bundle，.Net Core SDK不是必须的，如果服务器上只做运行环境的话，但是考虑到做持续交付，得用到SDK完成编译、发布，因此还是装上SDK。此处以.Net Core2.2版本为例下载，然后执行安装，可能得注意下安装顺序，先安装SDK程序，后安装Runtime&HostingBundle程序，安装完毕后在IIS的模块页中查看刚刚安装的模块。

脚本一键安装并配置

通过Powershell中执行一整套命令完成IIS、.Net Core SDK和Runtime & Hosting Bundle的安装及配置工作，需要注意的是，该脚本中部分命令需要在Windows Server2008R2后的版本才能运行。

AspNet Core对接钉钉群机器人

Sat, 02 Mar 2019 10:00:00 +0800

钉钉作为企业办公越来越常用的软件，对于企业内部自研系统提供接口支持，以此来打通多平台下的数据，本次先使用最简单的钉钉群机器人完成多种形式的消息推送，参考钉钉开发文档中自定义机器人环节，此次尝试所花的时间不多，但有几个地方是需要注意的。

钉钉群中建立机器人获取WebHook地址

首先得有一个钉钉群，如果没有得自行创建一个了，通过群内右上角菜单中找到群机器人然后添加一个自定义机器人

并设置消息推送开启(默认是开启)，复制下一行的webhook地址，该地址将作为后面消息推送的地址

完成即可，如果不确定该地址是否有效可以用命令测试一下，比如在Linux平台下，通过该命令并将自己的webhook_token替换

curl 'https://oapi.dingtalk.com/robot/send?access_token=cd1eb120c459ced6a65491af7b1eebbc84790fb672077a969bae8bb203aa1c52' \
 -H 'Content-Type: application/json' \
 -d '
 {"msgtype": "text",
 "text": {
 "content": "我就是我, 是不一样的烟火"
 }
 }'

然后回车进行测试，即刻收到群机器人推送的消息

参考文档完成基础类的封装并处理相关字段

接下来开始在代码中完成对WebHook地址的调用，可以先分析一下群机器人的文档，可以获悉有五种消息类型：文本 (text)、连接 (link)、markdown (markdown)、ActionCard、FeedCard消息类型，其中的actionCard分整体和独立两类。针对这些类型及给出的参数要求完成基础类的设计和封装，以text类型为例：

其中的msgtype是五种消息类型的字符串，因此针对该部分设计一个枚举，作为消息类型的区分。

/// <summary>
/// 钉钉群机器人消息类型枚举
/// </summary>
public enum MsgTypeEnum
{
 text,
 link,
 markdown,
 actionCard,
 feedCard
}

设计一个text类并给定一个属性Content，在设计时我们喜欢使用帕斯卡命名法，但是钉钉接口却不允许，如果不做一些处理，直接使用Content属性将会调用不通接口，这点需要注意，使用Newtonjson提供的打包成json时用指定的名称替换来满足钉钉接口需求。

/// <summary>
/// 文本类型
/// </summary>
public class Text
{
 /// <summary>
 /// 文本内容
 /// </summary>
 [JsonProperty(PropertyName = "content")]
 public string Content { get; set; }
}

其次对指定人群做一个类的封装，同样需要处理其中的属性在序列化时的替换名称。

AspNet Core中HttpClient的使用方式

Tue, 26 Feb 2019 10:00:00 +0800

在.Net Core应用开发中，调用第三方接口也是常有的事情，HttpClient使用人数、使用频率算是最高的一种了，在.Net Core中，HttpClient的使用方式随着版本的升级也发生了一些变化，本次就讲解一下Asp.Net Core2.1前后使用的两种方式。

原先HttpClient使用方式

一般来讲，喜欢要用的时候才会选择去获取资源，因此，当在有需求时才会用HttpClient去调用资源，便会使用如下这种方式或其它方式获取资源。

//do something...
using (var httpClient = new HttpClient())
{
 var requestUri = "http://aspnetcore.online/api/resource/getresource";
 var httpResponseMessage = await httpClient.GetAsync(requestUri);
 //do something...


 return Ok(httpResponseMessage);
}

如果可以正常访问目标地址的话，则会返回相应的资源信息。又如Post方式提交并返回相应的内容，都是可以直接使用。

//do something...
using (var httpClient = new HttpClient())
{
 var requestUri = "http://aspnetcore.online/api/resource/postresource";
 var httpResponseMessage = await httpClient.PostAsJsonAsync(requestUri,"星城软件");
 //do something...


 return Ok(httpResponseMessage);
}

但是这种情况下会出现一个严重的问题，在不停的调用情形下，tcp连接数会被耗尽，虽然使用using方式调用HttpClient并在退出前调用Dispose()方法将HttpClient释放了，但是tcp连接仍然处于保持状态，在240s后才会自动断开，这里就涉及到一个连接状态了，首先得理解下http的工作原理，http协议是建立在tcp协议基础之上，当浏览器需要从服务器获取数据的时候，会发出一次http请求。http会通过tcp建立起一个到服务器的连接通道，当本次请求需要的数据完毕后，http会立即将tcp连接断开，这个过程是很短的。所以http连接是一种短连接，是一种无状态的连接。但是tcp的连接只要我们不通过代码把连接关闭，这个连接就会在客户端和服务端的进程中一直存在，相关状态数据会一直保存着，直到无响应状态持续了默认关闭时间后自动断开。当短期请求量过大时，这就可能导致了"套接字资源耗尽异常"，因此，为了解决这个问题，想到不释放HttpClient，将它作为单例一直使用，实现单例方式有很多种。

如使用单例模式，只生成一个HttpClient

private static HttpClient _httpClient = null;
public HttpClient CreateHttpClient()
{
 if (_httpClient == null) _httpClient = new HttpClient();
 return _httpClient;
}

亦或是在初始化时完成单例注入，创建一个IHttpClient接口，及相应的实现StandardHttpClient，实现类种加入HttpClient属性，在实现类构造函数中完成初始化后便可直接使用该实现类完成资源请求工作。

ABP框架开发-XAdmin前端

Thu, 21 Feb 2019 10:00:00 +0800

“站在巨人的肩膀上”，这样一来，不要万事亲恭，在值得的方向上节约时间，毕竟人生就这么一次。在接触ABP以来，一直想花点时间整合LayUI前端框架到ABP中，进而能够逐渐打磨出一套适合自己的框架，开发习惯、项目架构、界面风格等等。在年前花了点时间了解了LayUI现有的后台模板，虽然LayUI自家的LayUIAdmin很不错，但奈何于贫穷，因此绕道看看是否有前端同胞已经弄出来一份免费版的，比较了几份后台模板后，找到了合适的X-Admin。

演示地址：http://123.207.15.233:9527/

码云地址：https://gitee.com/530521314/Partner.Surround.git

X-Admin前端框架和ABP框架

X-Admin是基于LayUI打造的一套前端框架，比起Bootstrap那种粗犷的风格，LayUI更加符合国人的审美观，同时LayUI也对后端开发人员友好，在不完全掌握前端知识的前提下也能够进行项目开发，官网地址：http://x.xuebingsi.com/。

ABP框架是一个用最佳实践和流行技术开发现代Web应用程序的新起点，旨在快速搭建一个通用的Web应用框架和项目模板，集成着一些优秀的工具和思想，官网地址：https://aspnetboilerplate.com/。

如果觉得自己组合一套框架觉得繁琐，可以试试使用52ABP框架，该套优秀的前后端框架由梁桐铭在ABP框架的基础上进行整合，对于前后端相关功能进行改造，使满足国人的开发习惯，官网地址：https://www.52abp.com/。

开始整合两个框架

先从ABP官网下载项目模板。经过文件结构调整后，项目文件路径如下，之所以项目文件路径和官网下载下来的不完全一致，是经过了一些调整，适用自己的开发习惯，毕竟适合的才是最好的，在之前的生成流水线搭建中也提到过项目结构，目的是使之标准化，而不需要每次都要重新设置一下项目文件结构。(注意，此处我下载的是.Net Core+MPA版+去掉登录、注册、用户、角色和多租户功能)

下载X-Admin源码包，解压后，开始着手Ctrl+C、V操作，将需要的一些js、css等文件移入到ABP中。

去除在本次整合后部分在ABP中的不再需要的功能，如Boostrap及其相关的插件，并不是Boostrap不优秀而是LayUI是我的目的，功能相似下，没必要在冗余存在。

并在bower包管理中删除对Boostrap的依赖，尽可能的使用大部分LayUI及LayUI社区提供的插件和功能，以减少后端开发人员的学习和使用成本。

将X-Admin文件夹中的js文件及css文件移入到ABP中，部分ABP分装了一层的js、css保持不变，仍然先存放着，如果后期确定不再使用，再进行移除ABP下载后自带了一个main.css文件，可以使用这个文件或直接使用X-Admin中的css文件。

以现有的Layout母版页复制一个(此处我命名为_LayoutBase)，从X-Admin文件夹中查看index.html并复制Body标签内的代码到_Layout母版页的Body中(我对底部的footer删除了，位置不太合适)，整理引用的js、css文件，具体可见我的Git仓库中，使用控制器Home,方法Index的视图作为使用_LayoutBase母版页的视图，其余页面都将在Index界面中以iframe的形式出现，到现在，直接启动项目后，初步的界面可以展现出来了。

优化展示效果

X-Admin中，对于侧边栏收缩采用的是直接全部隐藏，在该功能的基础上改造一些功能，使得收缩后可以留下一列图标，实现方式可以有很多种，此处采取使用js脚本去控制左侧菜单宽度实现，在xadmin.js脚本中，找到**$(’.container .left_open’).click()**方法，然后在此基础上进行改造，如以下改造，注意，部分css也需要改造，具体见仓库源代码中。

$('.container .left_open').click(function (event) {
 if (!$('.left-nav #nav .layui-nav-item').hasClass('nav-mini')) {
 //左侧菜单
 $('.left-nav #nav .layui-nav-item').addClass('nav-mini');
 $('.left-nav').animate({ left: '0px', width: '60px' }, 100);
 $('.sub-menu li').each(function () {
 $(this).hide();
 });


 //右侧内容
 $('.page-content').animate({ left: '60px' }, 100);
 $('.page-content-bg').hide();
 } else {
 //左侧菜单
 $('.left-nav .layui-nav-item').removeClass('nav-mini');
 $('.left-nav').animate({ left: '0px', width: '220px' }, 100, function () {
 $('.sub-menu li').each(function () {
 $(this).show();
 });
 });


 //右侧内容
 $('.page-content').animate({ left: '220px' }, 100);
 if ($(window).width() < 768) {
 $('.page-content-bg').show();
 }
 }
});

加入语言为简体中文，在领域层中的本地资源配置中加入中文及中文语言包，此处我将中文设置为默认语言，更改原有默认的英文包的PithyDesign为PithyDesign-en，并增加一个PithyDesign.json内容与英文包一样，将英文译成中文即可。

增加中文并设置为默认选项，如有更多语言，可以在此基础上进行扩展。

Mysql常用基础操作(备忘录)

Sun, 13 Jan 2019 10:00:00 +0800

常常忘记mysql的一些命令行操作，甚至于说，比较复杂的sql格式记不住或忘记了，也可能根本不会考虑去记，因此，做一下汇总，当下次出现恍惚时不至于去百度挨个找，有时就是记不起来，但是只要给点药引子，立马会想起来。

基础操作

mysql命令规则：每行sql后边都跟个分号表示一个命令语句结束

1、登录本地mysql数据库

$ mysql -u root -p
$ password

2、更改root密码

mysql>mysqladmin -uroot password 'yourpassword'

3、登录远程mysql数据库(主机地址，端口号，用户，密码)

mysql>mysql -uroot -p -h192.168.137.10 -P3306

4、退出mysql

mysql>exit;

5、启动mysql服务(CentOS下)

systemctl start mysqld.service

6、结束mysql服务(CentOS下)

systemctl stop mysqld.service

7、启动mysql服务(CentOS下)

systemctl restart mysqld.service

数据库操作

1、创建数据库

mysql>create databases 数据库名;

2、删除数据库

mysql>drop database 数据库名;

3、修改数据库编码方式

mysql>alter database 数据库名 default character set 编码方式 collate 编码方式_bin;

4、查看所有数据库

mysql>show database;

5、切换数据库

mysql>use '数据库名';

6、查看当前数据库所支持的字符集

mysql>show charset;

AspNet Core&Docker部署到树莓派3B中

Mon, 07 Jan 2019 10:00:00 +0800

花了一点时间将吃灰数月的树莓派装上了Docker，并在容器中部署了一个Asp.Net Core应用程序，通过花生壳映射树莓派中的程序，可以使用外网访问树莓派，玩起来很有意思(外网访问地址：http://aspnetcore.online/，访问不通可能树莓派断电了)，过程中发现了一点问题，或许对于同样路线的朋友有所帮助，特此写出玩转过程。

码云Demo地址：https://gitee.com/530521314/ControlEvent.git

树莓派安装操作系统

进入官网下载操作系统：https://www.raspberrypi.org/downloads/，我使用了官方的Raspbian系统，并且选择了无界面的轻量版Raspbian Stretch Lite.

下载格式化SD卡的工具：https://www.sdcard.org/downloads/formatter_4/eula_windows/
下载将系统烧录到SD卡中的工具Win32 DiskImager：http://sourceforge.net/projects/win32diskimager/，选择系统磁盘路径地址，选择卡，然后执行Write即可，等待几分钟，便完成烧录工作

做一些配置工作，方便启动树莓派后可以快速玩转
1. 启动SSH，在卡分区内创建一个名为ssh的文件夹即可
2. 设置无线连接，本次我没有使用外接显示器到树莓派中，使用Putty工具直接无线连接，个人感觉更为方便，在卡内boot文件夹内，创建一个wpa_supplicant.conf的文件，并写下如下内容，该内容在树莓派通电后会由系统自动添加到/etc/wpa_supplicant/wpa_supplicant.conf中，设置完毕后便可以插入到树莓派，开始通电了

country=CN
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1


//WiFi没有密码
network={
ssid="你的无线网络名称（ssid）"
 key_mgmt=NONE
}


//WiFi使用WEP加密
network={
 ssid="无线网络名称（ssid）"
 key_mgmt=NONE
 wep_key0="wifi密码"
}


//WiFi使用WPA/WPA2加密
network={
 ssid="无线网络名称（ssid）"
 key_mgmt=WPA-PSK
 psk="wifi密码"
}


//以我的举例(priority连接优先级最高)：
network={
 ssid="Yang1802"
 key_mgmt=WPA-PSK
 psk="xxxxxxxx"
 priority=1
}

使用Putty连接树莓派，树莓派ip地址可以找办法查看（如我使用的华为路由器，则可以登录路由器管理平台查看），使用账号pi，密码raspberry完成登录，开始校正树莓派时间

// 设置时区为 亚洲（Asia） 上海（Shanghai）
sudo dpkg-reconfigure tzdata
// 启动 NTP 使计算机时钟与 Internet 时间服务器同步
sudo timedatectl set-ntp true

切换到root账号，方便操作

sudo su

KnockoutJS-与服务端交互

Wed, 02 Jan 2019 10:00:00 +0800

几乎所有Web应用程序都要和服务器端交换数据，交换数据时最方便的就是使用JSON格式。Knockout可以实现很复杂的客户端交互，对于前后端交互使用的技术最为基本且常用的是Ajax，本次利用Ajax和ko的双向绑定完成一些简单的功能，可以快速展示出ko的方便之处。

代码地址： https://gitee.com/530521314/Partner.TreasureChest.git

服务端返回数据绑定到客户端

准备好一些初始数据，直接通过View方法将视图实体返回到视图文件中。

前端设置为强类型，初始化ko并从Model中获取数据并加载到ko对象中，同时完成了页面渲染。(注意暂时未使用Mapping插件)

效果实现图

客户端通过Get请求服务端数据

通过前端请求，完成将服务端数据加载到当前页面中，使用$.get方法或是$.getjson方法或是$.ajax方法都行，本次直接使用$.get方法，当获取服务端数据成功后，清除界面上的已有数据，并将新数据循环绑定到viewModel中

服务端编写简单的方法，在原来基础数据的基础上增加一条新数据，并将数据打包成Json格式，注意将获取成功与否的操作结果返回

效果实现图

客户端POST提交数据到服务端(手动绑定)

前端数据提交到后端的方式可以有简单的get提交，提交几个参数跟在url后面，用于查询相关信息，也有使用post提交表单数据或是json或xml格式的数据，本次只使用一下post提交json数据

post提交单条数据，将单条数据转换为json格式，使用ko提供的直接将viewModel中的集合转换成json格式的数据，该过程也可以使用其它方式完成，并非完全依赖ko

服务端指定接收参数，完成相应操作返回结果，注意使用了FromBody特性，只允许最多一个参数，如果有多余参数要使用，则将参数打包成一个新的类，大多使用dto

前端提交整个集合到后台，先将集合打包成Json格式，然后使用ajax完成提交，操作过程中，由于集合是存在于observableArray的监控数组中，不能直接序列化，因此需要使用其它方式进行转换

在服务端使用List<>来接收，通过asp.net core提供的模型绑定，将前端请求中的json数据完成绑定到List集合中

效果实现图

客户端POST提交数据到服务端(自动绑定)

对于之前的一些操作，有些操作可以使用ko提供的插件直接帮助我们完成绑定工作，而无需进行大量属性的绑定工作和处理复杂的嵌套结构，如同在后端的AutoMapper工具，在ko中有一个ko.mapping插件，可以很大程度上提高我们的开发效率。

mapping插件使得JavaScript简单对象（或JSON结构）转换成Observable的view model，这样一来，无需在前端声明一些view Model类了。

从后台返回的List集合通过mapping插件绑定到前端viewModel实例属性中

获取服务端的List集合绑定到前端页面中，使用ko插件直接绑定

**注意：**在使用asp.net core时，服务端返回的json格式为驼峰式，当在上一步操作中，初始化时为首字母大写使用的是帕斯卡命名方式，并且在页面元素中也是使用首字母大写的形式，因此需要改变服务端默认的驼峰式规则。

在StartUp中，修改mvc的默认规则，使用Newtonsoft提供的转换方式，这样一来，前后端交互，前端绑定，传递到后端都是使用帕斯卡命名规则，对于前端来讲最好是使用驼峰式，同样也可以做相应的改变，比如对服务端视图模型属性中使用JsonProperty特性。

POST提交前端数组并序列化后到服务端中，后端控制器中并无修改，只在前端相应变化即可

至此，已完成了knockoutJS前后端交互的方式，对于其它表单提交等等，都比较简单，最后，祝大家新年快乐！。

2019-01-02，望技术有成后能回来看见自己的脚步。

KnockoutJS知识规整目录

Tue, 25 Dec 2018 10:00:00 +0800

对于Web开发来讲，前端接触是避免不了的，特别是对于中小公司，没有严格的职位区分，前后端人员互相身兼是常有的事情，使用一些好的框架，能够帮助我们快速开发并完成需要的功能，对于前端的JS框架来讲MVVM框架一直处于火热状态，现有名的三大巨头，Angular、Vue和React受众多人喜爱并且也用于公司项目或个人项目中，对于这三个框架，我接触的不多，只片面了解，从最早接触了WPF中的MVVM到转向Web时接触了一个由微软支持的MVVM框架：KnockoutJS，直到现在任然还是用这个顺手，借此还是巩固所学所用：

KnockoutJS知识自我总结：

2018-12-25，望技术有成后能回来看见自己的脚步。

服务部署到Swarm Cluster中

Sun, 23 Dec 2018 10:00:00 +0800

对于已存在的镜像，将其部署到服务器中并开始对外服务，便是它的职责，而我们要做的便是帮助它完成职责，前两个应用环节都已产生了相应的镜像，在这一环节，将完成服务部署到容器集群的工作，对于这一过程，实际执行中有很多种方式，毕竟一山比一山高，整个过程比较简单，镜像以任务形式下发到各容器主机即可，本次部署过程较为简单，只作为示例来讲，无需太多复杂过程，更强调过程实现。

选用部署方式

在之前的一篇文章：约定Service构建方式(https://www.cnblogs.com/CKExp/p/9940469.html))中提到了几种部署方式，对于我来讲，比较喜欢"借助工具手动交付"这种形式，一来，无需要面对命令行，借助工具去调用Docker Api，这样对于不太熟练使用的人也可以快速完成服务部署。

这里涉及到Portainer工具的安装，以及Portainer集群管理的安装：

单节点安装：Manager节点上安装Portainer，Swarm Cluster中没有Worker节点时直接使用这个即可，访问9000端口，配置账号密码即可管理。

$ docker volume create portainer_data
$ docker run -d -p 9000:9000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

集群模式下安装，采用docker stack形式，完成所有节点的安装，这样一来可以在Manager节点中统一管理整个集群**(推荐)**

$ curl -L https://downloads.portainer.io/portainer-agent-stack.yml -o portainer-agent-stack.yml
$ docker stack deploy --compose-file=portainer-agent-stack.yml portainer

Portainer文档：https://portainer.readthedocs.io/en/stable/index.html 配置镜像仓库地址：选中左侧菜单:Registries->Add registry选择Custom registry，添加一个镜像仓库地址，本次我使用的是腾讯云镜像仓库，因此仓库地址填写腾讯云仓库地址，同时使用身份认证，打开Authentication选项，输入腾讯云提供的账号密码：

腾讯云镜像仓库教程：https://cloud.tencent.com/document/product/457/9117

完成部署工作

创建Service

左侧菜单选择**Service，**点击增加一个Service，来开始服务部署工作。

然后填写一系列信息，如服务名称、镜像名称及版本号、选择镜像仓库地址，在Scheduling mode处如果选择Relicated则填写实例数量，可用于动态控制，如果选择Global则一台容器主机生成一个容器，填写对外端口(推荐填写)，不填则会被默认分配端口，开启钩子，当镜像版本进行更新后，通过生成的Url地址可以控制自动更新服务**(重点)**，镜像仓库大多提供触发器功能，通过镜像仓库中版本的更新，触发服务对新版本的获取从而达到持续部署功能，在腾讯云镜像仓库中提供了这一功能，通过webhook,可以帮我们实现持续部署，因此，当开启了钩子功能后，从代码的更改到镜像的更新再到服务的更新这一整个环节便能很流畅的进行了,当然这个前提是，需要容器集群在腾讯云中部署，如果是混合云等或是没有在腾讯云中建立容器集群，则这一功能是用不了的，只能另想其它办法触发服务更新。

创建完毕，服务部署便完成了，点击左侧Swarm菜单可以查看集群及服务运行情况。通过其它操作，如动态扩容、版本更新、版本回滚等操作，完成对服务的控制。

使用WebHook完成镜像更新则立马更新服务

本次我使用腾讯提供的TencentHub中的WebHook功能，腾讯云镜像仓库中的WebHook仅限把服务部署到腾讯云容器服务中，有点局限性，因此将镜像仓库转移到TencentHub中，在Service创建完毕后，得到提供的WebHook回调地址

然后在TencentHub中新增加一个**WebHook通知,**填写相应的信息和回调地址，选择镜像更新时则触发回调，便可以达到镜像更新则服务更新功能了

至此，服务部署到容器集群中算是完成了，操作过程较为简单，或许对于现有出色的生成流水线，如Azure DevOps等来讲，遥不可及，算是完成了一定的功能，旨在掌握整个生成流水线的过程，重在学习！

2018-12-23，望技术有成后能回来看见自己的脚步。

新建项目加入到生成流水线中

Thu, 20 Dec 2018 10:00:00 +0800

整个生成流水线已经搭建完毕了，这一次来从零开始融入到生成流水线中，从仓库建立到镜像生成整个过程，对于之前几篇文章的一次应用过程，注意，本次建立过程是保证在前期基础搭建完毕后的应用阶段，本次搭建过程较为简单，只作为参考示例，并无技术含量。

码云中新建项目

在码云中新建一个项目，取名为Standard，作为一个示例项目名，仓库地址：https://gitee.com/530521314/Standard.git

将仓库拉取到本地，开始在本地构建项目，我直接使用VS的Git工具

新建解决方案+项目

新建空白解决方案，指定方案名和路径地址

添加src文件夹到解决方案下(用于项目结构上区分)

添加应用程序，选择Asp.Net Core Web应用程序

**注意：**此处直接新建项目的位置为src文件夹下，主要是为了标准化搭建，前期文章也提及了。

配置需要的脚本文件

增加docker compose，选中项目右键添加->容器业务流程协助程序支持，弹框内选择目标平台，此处我选择为Linux，将dockerfile和docker-compose文件都一并加入到项目中了。

加入进来后的项目结构

对于docker compose脚本，没有必要在项目结构中展现，选中后右键将其卸载并移除。同时处理一下文件夹中的docker-compose，修改一下项目结构，增加docker文件夹，并将obj文件夹、docker相关的4个文件移入到docker文件夹中

最终项目结构：gitIgnore文件(手动配置或使用模板)，docker文件夹主要负责docker-compose脚本，src主要为应用程序及其相关，如有更多其它项目，如单元测试、集成测试，则还可以加入test文件夹，如还有文档资料，则还可以加入Document文件夹

修改docker-compose.yml中dockerfile位置(主要修改content)，修改image地址为镜像仓库地址，镜像版本前期使用latest，后期稳定部署时改为数字值

全部整理完毕后，执行代码提交并推送到仓库中

Jenkins中新建项目

具体的在Jenkins中新建项目可以参见该文章：https://www.cnblogs.com/CKExp/p/9940479.html，在此只处理执行脚本：

镜像生产

#!/bin/bash
# 获取短版本号
GITHASH=`git rev-parse --short HEAD`
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml -p standard down --rmi local --remove-orphans
# 生成容器及镜像等并对外提供服务
# docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml -p standard up -d --build
# 只生产镜像
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml -p standard build

镜像推送到镜像仓库中

docker login -u=xxx用户名xxx -p=xxx密码xxx ccr.ccs.tencentyun.com
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml push

保存并构建，查看控制台输出，构建成功

约定Service构建方式

Mon, 10 Dec 2018 10:00:00 +0800

对于DevOps中，将开发好的软件交付给运维人员去部署与维护，过程中参杂着诸多不可控制的变量，如环境问题、版本问题等等，而Docker容器极大程度上解决了这些问题，同时对于服务的持续交付，也变得方便和简洁，本次讲讲我的整个生成流水线中服务部署方面的一些想法和执行方式，或许不是很中意的想法，并且还可能被认为存在漏洞和错误，但是，至少是这个环节是通了的。最完美的前提至少是运行完成，在设计过程中，考虑到了几种情况，主要是针对服务器中镜像生产者和服务承载者之间的关系，也有不同的实现方式。

无需交付

镜像生产和服务部署共用服务器集群，服务器之间通过Docker Swarm完成集群，同时Docker Swarm中的Manager与镜像生产者在同一台服务器上，管理整个服务集群。

**注意：**仍然需要将生产完毕的镜像推送到镜像仓库中，因为在同一个集群中的其他Worker节点需要指定镜像下载，镜像生产结束后，推送到仓库，此时发起一个创建服务或是更新服务的命令，指定本服务器上的集群完成相应工作。在交付服务时，可以有两种方式进行交付，采用单个服务的创建脚本docker service create或是采用多个服务的批量创建脚本docker stack deploy指定.yaml文件，将.yaml文件中的服务进行批量创建或更新。

对于多个服务的创建脚本，我没有去尝试，有兴趣的可以查看Docker官网相关资料，对于单个服务的创建或更新脚本可以采用命令行方式或是使用UI工具去完成创建和更新，如使用Portainer工具，在Portainer中操作是很方便的。

手动交付

当镜像生产者和服务部署分离时，通常也是这种情形，镜像生产者只作为镜像的生产，职责便是生产镜像，而作为部署服务器，职责便是承载服务，对外提供服务。这个过程中就存在着，服务由谁创建，什么时候更新，由谁更新的一些问题，对于这些问题，也在一步一步设计中解答，本次先使用手动交付的形式，使用命令行来完成服务创建和更新，当镜像生产完毕后，便是交付环节，手动交付是最为基本的交付方式了。

通过命令行方式完成手动交付：

在Jenkins中使用命令行完成交付，当镜像生产完毕，执行创建服务或是更新服务，这有点随着镜像的变更而变更，无需人为操作，但是也是有问题的，就单个来讲，镜像的变更往往是由开发人员将代码合并到主干中，才触动镜像更新，这也在一定程度上受限于合并到主干的时机，如果合并太过频繁，则镜像生产者需要连续生产，并且中间的镜像生产过程变得毫无意义了。
在Swarm Cluster内使用命令行创建服务完成交付，在Swarm集群中的Manager节点上单个操作，是可行的，如果集群数量少，且没有安装图形管理工具之类的，可以使用这种方式，只是如果Swarm Cluster数量过多，需要一个一个切换\登录，也是比较繁琐的。
在其他主机上操控Swarm Cluster使用命令行完成交付，这个过程同直接操作Swarm Cluster也是差不多的，只是可以使用额外的管理主机管理多个Swarm Cluster的Manager节点，这样一来，也较为方便，直接在一台非Swarm Cluster内的主机上即可完成所有Swarm Cluster的创建和更新过程。

图例：直接在Jenkins所在主机上操控Swarm Cluster完成交付

借助工具手动交付

对于命令行来讲，多条复杂命令总是难记，有可以直接操作的工具往往是更受欢迎的，而对于Docker来讲，Portainer工具是极受欢迎的，快速安装，简单的操作界面，丰富的功能等，同样还有其他不错的图形化容器管理工具，如Seagull、Shipyard等。

利用Portainer工具完成手动交付，在Portainer界面中，配置好仓库地址和用户名密码，便于私有镜像的拉取，至于仓库，可以是自己搭建的镜像仓库，也可以使用第三方提供的镜像仓库，如阿里云、腾讯云镜像仓库。

利用其他Docker及Docker Swarm集群管理工具完成手动交付，至于使用其他的工具，我也没有使用过，但是工具只不过是将命令行进行了分装，因此，其他图形化管理工具也是应该存在这些功能。

图例：利用Portainer工具操控Swarm Cluster完成交付

借助工具自动交付

对于自动交付，这个功能，只是见到过其他人这么玩过，猜想了一下工作方式，至于实际尝试，并没有去做，因为思考了一些操作过程，感觉我对这个自动交付的环节并不太感冒，因为按照生产来讲，追求稳定才是重要的，如果存在测试人员，测试相应服务完毕后，推送测试好的镜像，这是运维人员将镜像交付到生产环境中，能够保证不出差错，虽然失去了效率，但是也在是心安理得。至此，我只能简单描述下借助工具完成自动交付过程，在Docker Swarm集群中的Manager节点或单独弄一台服务器作为镜像更新后的交付服务器，在服务器中加入Jenkins工具，指定镜像版本更新，则拉取最新镜像完成服务更新，镜像首次推送，则完成服务创建，对于使用批量创建/更新服务的脚本文件，没有使用的太深，但是那个是非常有价值的。

至此，几种我用过的方式也讲完了，在其中对于docker stack deploy使用的较少，因为docker stack deploy使用场景是为了批量服务的创建和更新而存在的，如果对于单个服务我都使用这个命令，有点杀鸡用牛刀的感觉，而对于以后的k8s学习，使用批量服务创建更新脚本文件，将会是常态。目前我现在采用的是“借助工具手动交付“这种方式，原因有几点，主要是，思考了下，服务交付的意义，主要是为了稳定，少出问题，必须在确保稳定后才能交付部署，经测试人员测试完毕后完成交付到生产环境，这应该是我们所希望能够见到的，无论开发人员每天或每周有多少个版本更新，经测试人员测试后的稳定版本，才能交付到生产环境中，而不是说开发人员一将分支代码合并到主干中，有新的镜像生成了，就直接将新的镜像推送到生产环境中，而做到所谓的持续交付的目的，实际的持续交付应该是保证测试完毕到生产部署这个环节具有连续性，稳定性，每一次交付都经得起推敲，具体其中发生了什么，稳定性如何等，虽然这种方式效率较低，但对于持续交付来讲，这个效率也算是可以接受的。

2018-12-10，望技术有成后能回来看见自己的脚步。

约定Jenkins构建脚本

Sat, 01 Dec 2018 10:00:00 +0800

对于Jenkins的使用，我感觉只用到其中一小部分功能，但也就是这一小部分功能，也推动了整个CI/CD的过程，Jenkins的使用方式有很多中，可能我用到的只是其中一种，但是已经满足我的需求，便不再贪婪，本次要约定好Jenkins中的脚本规则，对于我的整个生成流水线来讲，约定至高无上，遵从约定，或许会出现错误，但出现的几率肯定低于不遵从约定，随意设计好的多。

Jenkins安装及项目配置

Jenkins安装

在以前的博客中已经介绍过Jenkins的安装，我使用的是在Docker中安装Jenkins，利弊明显，在容器中安装方便，但是也带来一些问题，如不能很好的和Docker Machie结合使用，如果想在Jenkins脚本中分发服务到其他主机上，那必须要在Jenkins中额外安装SSH插件。而在主机上直接安装Jenkins，则步骤要多一点，需要安装Java环境等操作，但是可以在Jenkins中直接使用Docker Machine的功能，直接将服务分发到Swarm服务器集群中，这便带来了优势。

Docker中完成Jenkins安装：https://www.cnblogs.com/CKExp/p/9536864

Jenkins集群搭建

对于Jenkins的作用需要重申重要一点就是，在我的整个生成流水线中Jenkins的最大目的是担任奶妈角色，也就是镜像的创建，甚至整个Jenkins集群的目的都是镜像的创建，在聊天时发现有人在自己的每一台机器上安装Jenkins,然后搭建Jenkins集群，然后将构建任务下发至子节点中并构建完毕后生成服务，我的思路在刚开始使用Jenkins时甚至也是这样，但是慢慢的我发现不对，这整个思路就是荒谬，难不成我的每一台机器上都得安装Jenkins，逐步探索，总结出来就是，Jenkins只是奶妈，最终目的只是镜像生产者。

Jenkins集群搭建过程：https://www.cnblogs.com/CKExp/p/9541137.html

Jenkins中新建项目

在我的生成流水线中，Jenkins的主要职责便是将代码仓库中的代码拉取过来，完成镜像的构建，而对于Jenkins中，构建项目，有一些需要设置的地方，如Git地址，凭证，构建时间，构建脚本等。

Jenkins中新建项目：https://www.cnblogs.com/CKExp/p/9940479.html

约定Jenkins的构建脚本

利用在构建Jenkins脚本时加入的Docker Compose工具，可以在脚本构建时生成多个镜像，且可以有依赖关系，方便相互关联的服务部署。

利用Docker Compose中的参数 -f 指定项目中的compose.yaml文件，这个文件的位置在之前约定项目结构中设置好了，在docker文件夹下，对于docker compose，会将这两个yaml文件合并为一个，因此，可以设置多个yaml文件，用于不同的作用。通过制定-p 参数来设置项目名称，down 参数将删除指定的镜像、服务、容器、网关等，对于构建镜像的命令，可以使用up命令或是build命令，两者区别是，使用up命令时会在本机上生成指定镜像的容器，而build命令则只负责构建镜像。

约定项目文件结构：https://www.cnblogs.com/CKExp/p/9940457.html

#!/bin/bash
# 获取短版本号


GITHASH=`git rev-parse --short HEAD`
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml -p multimap down --rmi local --remove-orphans
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml -p multimap up -d --build
# docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml -p multimap build

注意：如果不指定-p 参数，则会使用默认文件夹名，在此处为docker文件夹名，则会带来一系列问题，如对于默认网关名称，镜像名称等，都是使用docker开头，这就导致多个项目会发生冲突，都是使用docker开头的网关，多个项目只能一个有效，因此约定每个项目在指定-p参数时以项目名称为主。

镜像构建完毕，将镜像推送到镜像仓库中，指定仓库地址，用户名和密码(我这里使用的是腾讯云的镜像仓库，如果使用的私有仓库或其他云的，则需要替换)，可以利用docker-compose提供的push命令，将docker compose中生成的镜像都推送到镜像仓库中。

echo ---------------Push-Images...------------------
docker login -u=xxx用户名xxx -p=xxx密码xxx ccr.ccs.tencentyun.com
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml push

(可选)如果需要将创建服务到Swarm集群(或是k8s中)，也可以利用Jenkins完成，如果是将Jenkins安装在宿主机上，则可以使用如下命令创建服务：

首先执行登录仓库功能：

约定新项目的搭建流程

Tue, 27 Nov 2018 10:00:00 +0800

对于个人而言，项目文件结构我比较关心，一方面我能熟练操作各块文件夹，当需要改动时，能够立马进入到相应文件夹进行修改，另一方面，有新的成员后，能够看到项目文件结构，可以快速适应到环境中来，参照了一些名气很高的框架如Abp，EshopOnContainers等，也从中提炼一些项目文件结构，来约定好自己的搭建习惯，或许不是每个人的预期想法，也或许感觉我的项目文件结构很怪，不要感到奇怪，毕竟没有一劳永逸的事情，每件事情都在动态发展中(强力甩锅)。

约定项目文件结构

预期项目文件结构如下，约定之后，或许我的每一个demo都会遵从如下的结构来设计，如果说开发过程中发现有些问题，也将慢慢调整，参照了Abp来设计，但是只是用到里面最深的那一级，对于大小项目而言，能够先在标准化的道路上走，才有可能实现超车或起飞，因此先跑起来。

结构说明：

对于docker文件夹，目标是使用到其中的docker compose相关的一些文件，如使用docker-compose.yaml再加一个.yaml文件组合使用用来构建多个服务所需要的镜像，同时使用docker-compose.yaml再加一个service.yaml来构建服务，在docker中可以通过docker stack deploy来启动多个服务，同样在k8s中也是使用的相应的.yaml文件。
对于src文件夹，主要是用来放项目相关的，如接口或是mvc之类的应用程序及其相关的类库等，对于对外服务的应用程序，每一个中都指定了Dockerfile,这个Dockerfile文件无需手动配置，虽然也可以锦上添花，但我觉得用VS生成的已满足我的需求了，然后约定expose的端口为80，虽然有了compose文件后，这个端口指定与不指定已经意义不大了，毕竟优先级有限。
对于test文件夹，针对测试人员或是开发人员好单独管理单元测试或集成测试而单独分割出来的一部分，方便管理。
对于tools文件夹，针对运维人员执行数据库的迁移准备的，至于可能有更多的其他辅助类的项目加入进来也是有可能的，比如监控工具等。
对于其他文件，对于整个项目权重不占比太大，故不再提及。

搭建一个标准化项目

首先重申下这句话，对于项目搭建按照标准化的流程去设计，不管项目多大，按照固定标准化去设计，规避一些错误，使得针对项目开发的速度提高。

或许每个人的搭建方式都会不一样，按照我的习惯来搭建会是如下过程：

首先在码云或是GitHub中先建好一个仓库，并克隆仓库到本地；

其次，新建一个空白解决方案，这是很重要的一环，不要先建设Web然后再来改解决方案名字，会出现适得其反的效果；

在空白方案下新建解决方案文件夹src和test的文件夹，建完后直接查看文件夹内发现并没有生成文件夹;

然后在解决方案中选中src文件夹，右键新增项目，选中Asp.Net Core应用程序，取完应用程序名字，对默认路径做修改，在尾巴上加上\src，将其放置在src文件夹下，选择完毕后，应用程序加入，相应的文件夹下也出现了src文件夹，同样test文件夹也是如此;

**注意：**虽然在解决方案下添加也可以指定文件存放路径，同样在相应的文件夹内，但是生成的应用程序是在解决方案下，需要手动拖入，为避免这一烦扰，最好使用固定流程，先建立文件夹，然后再文件夹内选择新建项目，这样一来生成的应用程序将直接是处于该文件夹下，标准化软件开发设计必备的文件夹，具体的app项目和类库分别建设到这两个文件夹下;

其次，在src和test文件夹同级建立docker文件夹，不将其引用到解决方案中，避免在window下调试，docker文件夹中应包含整个解决方案的docker compose相关的脚本信息,如有必要可以在docker下在建立mvc文件夹，在其中放置脚本，当有多个版本出现时，可以用来区分，但是为了标准化来讲，如果这么做了，在Jenkins构建脚本时得注意文件夹路径(我不会选择分成多个文件夹)，建议是可以分成多个.yaml，取成不同名字来处理镜像和服务。
选择Web.MVC或Web.Host点击右键添加Docker支持，加入Dockerfile文件，内部原有端口改为80端口，如果有端口需求可以改为其他，默认的话就统一约定为80端口;
对于docker文件加入.yaml文件，点解决方案选择添加容器业务流程协调程序支持，选择Docker Compose，加入到指定文件夹中，(本地我没有这个项，我是采用手工方式直接加入到docker文件夹中，很low)。
对于docker-compose.yaml中针对镜像生成的部分，按照现在的搭建流程来将，其中的build参数的相关信息得指定成如下所示，注意不要在.yaml文件中使用Tab按键：

build:
 context: ../
 dockerfile: src/Surround.Web.Host/Dockerfile

**路径说明：**context的路径指定为本yaml文件上两级，为项目文件夹，然后指定为src下具体程序然后项目内Dockerfile。

最后，再次重申这句话：对于项目搭建按照标准化的流程去设计，不管项目多大，按照固定标准化去设计，规避一些错误，使得针对项目开发的速度提高。

2018-11-27，望技术有成后能回来看见自己的脚步。

设计生成自动化流水线

Sat, 24 Nov 2018 10:00:00 +0800

现在已经有很多成熟的生成流水线了，如Azure DevOps，直接在界面中配置好即可，相当便捷，生成流水线的工作方式、工作过程也可以简单了解，我在空闲时间搭建了一个简单生成流水线旨在巩固个人对生成流水线的理解。

生成流水线设计图

平时，在腾讯云、阿里云搞活动时薅了点羊毛，搞了几天便宜的服务器，不能让这些服务器闲置了，也借此来试试搭建一条流水线，目的是在于，一个新项目要开始弄，在我选择一个Asp.Net Core并推送到码云中，然后在Jenkins中做一些相关的配置即可，后期代码上的变更不会影响部署环境的变更。主要原因在于，看到过几次先开发后部署，然后遇到的一些部署方面的问题出现耽搁，因此，先把环境部署完毕，后期要做的只是将业务代码的不断加入进来，并且对上可以看到工作成果，如同高楼建筑，可以看到一层一层的往上叠加。

代码方面：Asp.Net Core、Git、Gitee
服务器方面：Jenkins、Docker Machine、Docker Compose、Docker Swarm
镜像仓库：腾讯云镜像仓库

设计过程中见到的多条道路

在设计过程中发现有些地方可以有多种方式实现，谈谈我所见到的几种方式：

单台服务器

代码存储在码云或是GitHub中，
可安装Jenkins可以安装到容器中或主机上，
可安装Docker Compose到容器中或主机上，更方便的启动/停止批量容器，
在Jenkins中使用脚本时：
可以选择用简单脚本启动/终止容器(docker run/stop)。
可以选择用Docker Compose启动/停止批量容器(需要代码中提供docker.compose.yaml文件)。
可以使用代码或是主机内的脚本文件启动/终止容器(使用.sh脚本文件)。
代码变更，利用jenkins定时拉取变动，然后重新部署容器，很简单和方便的实现持续交付与部署。

多台服务器

代码存储在码云或是GitHub中，
可安装Docker Machine到一台服务器上，然后快速的通过这一台服务器把其他服务器的docker环境搭建好。
可安装Docker Swarm,我暂时还只是用Docker Swarm，对于k8s没有涉及，所以暂不应用，对于Swarm的使用，我之前是有4台主机，因此在安装了Docker Machine的那一台就直接发起了一个集群，并把其他服务器也加入了进来，形成了如下局面：
![195736023_d9dfc3e2-77c0-4a4e-ba47-3be5fac20d83](https://raw.githubusercontent.com/ViatorLife/document-img/main/img/20181124/195736023_d9dfc3e2-77c0-4a4e-ba47-3be5fac20d83.png)
虽然，看起来没得什么问题，同样也可以使用，但是对于Host1来讲，负担太大，既作为奶妈(镜像生产者)又要作为奶爸(集群管理者)。因此为将压力分离一部分，也就有了下面的局面：

可安装Jenkins可以安装到容器中或主机上，
可安装Docker Compose到容器中或主机上，更方便的启动/停止批量容器，
在Jenkins中使用脚本用于构建镜像时：
可以选择用简单脚本删除原有镜像、构建镜像、启动、终止容器等(docker rmi/build/run/stop)。
可以选择用Docker Compose删除镜像、重新构建镜像、启动/停止批量容器等(需要代码中提供docker.compose.yaml文件，在该文件中指明build参数，Dockerfile位置)。(注意docker compose文件区别，一种是用来构建镜像的docker compose.yaml文件，这种指明了build和context，一种是镜像名称是指定了的，这种用于docker stack deploy，必须要在镜像存在的情况下才能用的。)
可以使用代码或是主机内的脚本文件删除镜像、重新构建镜像、启动/终止容器等(使用.sh脚本文件)。
我使用的是腾讯云的镜像仓库，用于存储构建后的镜像，并在swarm集群中拉取镜像部署服务。
代码变更，利用jenkins定时拉取变动，然后重新构建镜像，并将镜像推送到镜像仓库中，同时将更新swarm中的service，使用最新的镜像，滚动更新集群中的容器。在这里更新swarm中的service有多种方式，如果Jenkins是安装在主机上，那么可以直接在脚本中通过docker-machine ssh host2 相关更新命令，完成通知即可，如果Jenkins是安装在Docker中，那么Jenkins中需要安装SSH Plugin插件用来连接远程主机，然后执行更新。还有的方式就是，我不通知swarm集群，Jenkins服务器可以充当测试服务器，当测试人员测试完毕后，在swarm集群内通过命令手动更新service或是借助UI工具如portainer来手动更新service，更有甚者，在swarm manager节点上在安装一个Jenkins，用来拉取最新镜像(镜像更新触发拉取动作)，然后更新service,这种方式我暂时没有尝试过，应该也是行的通的。

现有集群环境如下

目前，搭建好了如下环境，对于镜像构建方如何通知swarm集群更新，还没有做到自动更新，暂时使用手动在swarm集群中更新，而对于镜像构建方的自动构建和镜像推送到镜像仓库现已完成。

在Swarm集群中，安装Portainer集群版本，可以监控整个集群的信息，对于手动更新来讲是很方便的，在Portainer中，在左侧有一个registry的菜单，点击进入后选择自己的仓库地址，用来配置我在腾讯云的仓库信息。

在Portainer菜单Service中可以创建或更新service，获取最新的镜像完成更新操作,相比用命令行去操作轻松许多。

后期将会完善自动通知swarm集群更新service功能(至于要不要这个功能，需要斟酌一番)。

2018-11-24，望技术有成后能回来看见自己的脚步。

ABP框架开发-Docker部署

Sun, 11 Nov 2018 10:00:00 +0800

本文旨在将Abp项目部署到Docker容器中，借助Gitee存储，Jenkins持续构建，利用Docker Compose生成镜像、启动镜像，在官网给定的Abp项目中，虽然用到了Dockerfile、Docker Compose，但是没有资料指明该如何使用这两个文件，借此我通过改造这两个文件来完成Abp部署任务。

前期准备工作

把从Abp官网下载下来的项目(我这取名为Surround方便讲解)修改成以下项目路径结构：

其中的docker文件夹中加入Docker Compose项目，点击具体项目(如ABP中的Web.Mvc)右键添加菜单中的容器业务流程协助程序支持，将出现一个docker compose项目，对于整个docker compose项目的路径按照约定设计。

处理docker compose中的脚本配置，在docker-compose.yaml中指定两个服务相关信息，镜像名称、dockerfile的路径地址，此处在build中指定context为本目录的上级目录，按照上图中的位置就是在/xxx项目这一级，然后指定dockerfile的路径为src/Surround.Web.Host/Dockerfile指明具体的Dockerfle路径，同样对于surroundmvc同样如此处理。

version: '3.4'


services:
 surroundhost:
 image: ${DOCKER_REGISTRY}surroundhost
 build:
 context: ../
 dockerfile: src/Surround.Web.Host/Dockerfile
 surroundmvc:
 image: ${DOCKER_REGISTRY}surroundmvc
 build:
 context: ../
 dockerfile: src/Surround.Web.Mvc/Dockerfile

对于docker-compose.override.yaml文件，这是对前一个文件的补充，docker compose会将两个文件进行合并，在此文件中指定环境变量和对外端口此处docker compose设置的端口优先级高于dockerfile设置的端口，此处设置后dockerfile的端口则失效，此处设置内部端口为80端口，外部端口随机获取一个，如果想固定端口，则可以写 - “32100:80” 那么外部端口便固定为32100。

version: '3.4'


services:
 surroundhost:
 environment:
 - ASPNETCORE_ENVIRONMENT=Development
 ports:
 - "80"
 surroundmvc:
 environment:
 - ASPNETCORE_ENVIRONMENT=Development
 ports:
 - "80"

选中Surround.Web.Mvc点击右键选中添加，加入新的dockerfile文件，不再使用已有的dockerfile文件，同时建议修改dockerfile中的指定端口为80端口，这样就促成了约定所有的新项目加入进来容器内部都使用80端口，如有需要另改即可，同样对Surround.Web.Host也执行这样的操作。

新建项目到Jenkins中

Sun, 11 Nov 2018 10:00:00 +0800

在以Jenkins为镜像创建Docker容器时，我们在jenkins的dockerfile文件中写明了要安装Docker Compose，目的也是在Jenkins容器中借助Docker Compose来完成相关的操作。

容器中安装Docker Compose

同时安装Jenkins和Docker Compose：参照之前写过的文章安装Jenkins的同时也安装Docker Compose: https://www.cnblogs.com/CKExp/p/9536864.html，安装完毕，开始安装jenkins内部的插件，如有安装失败的插件，点击Retry重新安装。如果发现jenkins缺少东西，需要重装，则把/var/jenkins_home文件夹整体删除，重新安装。
只安装Jenkins，再进入容器后安装Docker Compose,进入Jenkins容器中 $ docker exec -it 容器ID /binbash 然后参照官网文档进行安装：https://docs.docker.com/compose/install/#install-compose

在Jenkins中新建项目

首先把系统时间修改一下，使用中国时区，在系统管理，脚本命令行中写入如下代码设置jenkins中的系统时间同步北京时间，方便后期做定时删除无效镜像使用。

System.setProperty('org.apache.commons.jelly.tags.fmt.timeZone', 'Asia/Shanghai')

点击新建项目按钮，输入一个项目名称。

配置项目的Git路径，如为私有项目，则增加凭证(Credentials)。

构建触发器,定时两分钟检查一次查看Git中是否有代码变更，

设置构建时间(建议将时长分配多一点，如果构建复杂应用，构建过程将会耗时很长)。

构建过程脚本，在这里使用docker compose完成相应的功能，

构建脚本具体如下，在此过程中指明了两个.yaml文件的具体位置，以项目的根目录为基准进入docker文件夹找到两个.yaml文件，然后docker compose将两个文件合并，停止并删除本地已有的容器、镜像、网桥、数据卷，然后重建：

#!/bin/bash
# 获取短版本号


GITHASH=`git rev-parse --short HEAD`
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml -p surround down --rmi local --remove-orphans
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml -p surround up -d --build

或可以使用如下命令，不在本地生成容器，而只生成镜像即可

#!/bin/bash
# 获取短版本号


GITHASH=`git rev-parse --short HEAD`
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml -p surround down --rmi local --remove-orphans
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml -p multimap build

将镜像推送到镜像仓库中，方便后期的服务部署工作。

echo ---------------Push-Images...------------------
docker login -u=xxx用户名xxx -p=xxx密码xxx ccr.ccs.tencentyun.com
docker-compose -f ./docker/docker-compose.yml -f ./docker/docker-compose.override.yml push

保存，配置结束，点击开始构建。

生成流水线搭建过程目录

Sat, 10 Nov 2018 10:00:00 +0800

设计初衷，之前有过手动维护五个项目的经历，且项目之间存在关联关系，当时是用Docker承载，也没有使用Jenkins，直接在服务器上装了Git，把代码Pull下来，然后靠手动执行编译部署，每次新代码进来，需要进入到每一个Docker容器中执行编译然后运行，哪个有改动，就进哪个容器中，在那时感觉也没什么，无非是感觉加大了点工作量，至少是还能解决问题，可是当连续多次这样操作之后，繁琐感油然而生，如果项目在多一些，整个开发工作时间怕是要折半了，得花大把时间去维护这些部署工作，当时花了点时间找博客学习，也学到了一些新东西、新工具，多次磨合、使用后，慢慢地也就开始将学到的融合在一起，构建一个简单的生成流水线，至少确保了新代码加入后，不要手动去维护了，还获得了一些额外的好处。

本次基于Asp.Net Core、Jenkins、Gitee、Docker、Docker Machine、Docker Swarm、腾讯云镜像仓库和Tencent Hub搭建生成流水线，并确保新项目按照标准化流程搭建并推送到码云中，简单配置Jenkins后便能够生成且可以直接浏览。

生成流水线搭建目录如下：

五、配置流水线中的Docker Machine

六、配置流水线中的Docker Swarm

七、新建项目到Jenkins中

八、实例：把ABP加入到生成流水线中

九、实例：新建项目加入到生成流水线中

十、实例：服务部署到Swarm Cluster中

2018-11-10，望技术有成后能回来看见自己的脚步。

通过Jenkins定期清除为None的镜像

Sat, 03 Nov 2018 10:00:00 +0800

在代码持续交付过程中，依靠Jenkins生产Docker镜像时，会生成许多的名为None的中间镜像，这些镜像在整个项目生产过程完毕后意义不大，还占着空间，需要定期清理，通过手动方式实在是繁琐，也就有了定期清理。

手动方式清理

比较简便的清理方式，适合有单个none镜像产生时手动执行命令清理镜像，执行如下命令：

docker rmi $(docker images -f "dangling=true" -q)

由于我本地已经没有了none的镜像，因此执行就只能看到如下效果

项目生产结束后清理

在Jenkins中建立一个满足CI的项目时，生产过程完毕结束后清理可以在构建执行脚本内设置，如：

其中的脚本为：

echo ---------------Clear-Images...------------------
clearImagesList=$(docker images -f "dangling=true" -q)
if [ ! -n "$clearImagesList" ]; then
echo "no images need clean up."
else
docker rmi $(docker images -f "dangling=true" -q)
echo "clear success."
fi

当项目构建完毕后，执行这个，将本身构建过程中生成的None镜像清楚，做到自己清除自己的中间产物。但是有一个严重问题会产生，当两个或多个项目在同时构建时，先构建完毕后执行清除的脚本将会影响正在构建过程中的项目，删除正在构建过程中所产生的none，但是删除失败进而引发错误，导致先构建的项目构建失败，在多个项目的情况下不推荐这种方式，如果在Jenkins中只有单个任务在跑，那没得问题。

定时任务清理

比较喜欢这种方式，新建一个Jenkins定时任务，比如我设置为晚上十二点清理为none的镜像，步骤如下：

Jenkins中新建一个项目，名字随意，如我的为ClearImage。
构建触发器，选择Build periodically，设置定时时间，如我设置的是凌晨1时清理，也可设置其他时间，具体设置规则参见右边问号。

执行构建脚本，脚本内容在之前已经给出，保存完毕即可，

手动执行立即构建，验证是否有效：

查看控制台输出：

输出完毕：构建有效。

2018-11-03，望技术有成后能回来看见自己的脚步。

Docker Swarm搭建多服务器下Docker集群

Sat, 27 Oct 2018 10:00:00 +0800

对于有多台服务器来讲，如果每一台都去手动操控，那将会是一件非常浪费时间的事情，毕竟时间这东西，于我们而言，十分宝贵，或许在开始搭建环境的时候耗费点时间，感觉是正常的，我也如此，花费大堆时间在采坑和填坑的路上，但是当你踩完后，还通过手动管理的方式去维护，那便是折磨，因此对于多台服务器下的容器编排管理，借助工具将会节省着大把时间，现如今有名的容器编排工具，K8s、Docker Swarm，甚至功能更强大的Rancher，本次我将使用且是我唯一使用过的Docker Swarm工具搭建Docker集群并部署服务。

Docker Swarm官方文档地址：https://docs.docker.com/engine/swarm/

搭建前期工作

在之前的文章中，对于一台新的服务器加入到服务器集群中，通过Docker Machine去管理，配置好Docker Enginee环境，简单也方便，同时在配置时，将本地的私钥发送给了新的服务器，也就配置好了关联关系，如有需要可以查看该文章：https://www.cnblogs.com/CKExp/p/9552272.html

加入进来后对于整个服务器集群来讲，可预见的Swarm方式是这样的，也是最为简便的方式管理，Manager作为容器集群发起者，也是管理者，一般来讲，我会尽可能少的在上面部署服务，通过一些方式过滤掉服务在上面的部署，毕竟它的职责更多的侧重于管理整个容器集群，但是对于一些开支小的且比较稳定的服务，也是可以i直接部署在Manager节点中的，这是一种建议。

这是我当前的服务器下的容器集群，存在一个Leader也就是Manager，也可以设置多个，但是现有场景下，完全满足我的需求了。

我们利用Docker Swarm中的Docker CLI去创建集群、管理集群、动态扩容服务。而对于Swarm的版本，建议是Docker版本要高于1.13，在1.13之上，将Swarm功能集成到了Docker中，而对于1.13之下，需要单独设置Swarm模式，在此建议，使用1.13之上的版本。

在Swarm中有几个名字概念：

Node: 节点，分为Manager Node和Worker Node，在上图中有一个Manager节点和三个Worker节点,这个概念很好理解。
Service: 服务，对于Swarm而言，部署服务是它对外的职责，对于整个集群来讲，都是通过部署服务的形式，并且通过扩容、缩放来动态的决定服务数量。
Task: 服务的具体承载，在于Manager节点将服务分发到具体的Worker节点上，属于下达具体任务概念。相较于Service属于微观概念。

对于Swarm模式下，需要开启几个相关的端口，而在系统中，这几个端口是默认打开的：

TCP Port 2377：用于集群间通信，
TCP 和UDP Port 7946：用于节点间通信，
UDP Port 4789：用于Overlay网络方式下通信，这个是在集群模式下的网络通信方式，单机下采用的是Bridge方式。

搭建Swarm

在需要设置为Manager的节点上输入如下命令，开始容器集群搭建，IP地址写现在服务对外IP。

$ docker swarm init --advertise-addr <MANAGER-IP>

可以获得如下信息，集群创建完毕，复制该命令，在其他子节点上执行完毕，子节点便是加入了该容器集群(可通过docker-machine ssh xxx的方式快速进入到目的节点中执行)。对所有节点加入完毕，通过docker node ls命令查看节点信息，加入的节点和本身节点将会显示出来。

如果有新的服务器加入了，并且已经安装好了docker enginee需要加入到节点中且忘记了这一条token的值，可以通过在manager上执行该命令再次获得这个值

docker swarm join-token worker

至此，整个容器集群就搭建完毕，Manager节点和Worker节点都接入进来了。

部署服务到集群

进入到Manager节点，开始部署一个服务到容器集群中，通过如下命令创建一个服务：

$ docker service create --replicas 1 --name helloworld alpine ping docker.com

命令解读:

AspNet Core中服务的生命周期选项区别和用法

Sat, 20 Oct 2018 10:00:00 +0800

在做一个小的Demo中，在一个界面上两次调用视图组件，并且在视图组件中都调用了数据库查询，结果发现，一直报错，将两个视图组件的调用分离，单独进行，却又是正常的，寻找一番，发现是配置依赖注入服务时，对于服务的生命周期没有配置得当导致，特此做一次实验来认识三者之间(甚至是四者之间的用法及区别)。

Demo地址: https://gitee.com/530521314/Partner.TreasureChest/tree/master/ServiceLifetime

服务的生命周期

在Asp.Net Core中，内置容器负责管理服务的生命周期，从被依赖注入容器创建开始，等我们调用完服务时，到容器释放该服务的所有实力为止，有几种形式表现：

Transient：每次请求服务时，都会创建一个新实例，这种生命周期适合用于轻量级服务（如Repository和ApplicationService服务）。
Scoped：为每个HTTP请求创建一个实例，生命周期将横贯整次请求。
SingleTon：在第一次请求服务时，为该服务创建一个实例，之后每次请求将会使用第一次创建好的服务。
Instance：与SingleTon类似，但在应用程序启动时会将该实例注册到容器中，可以理解为比SingleTon还早存在。

应用程序中相关服务的控制生命周期的方法时通过相应的Add*指定，如下三种，当然还可以通过扩展方法来简化ConfigurationServices方法中所见的代码数量。

services.AddTransient<IApplicationService, ApplicationService>();
services.AddScoped<IApplicationService, ApplicationService>();
services.AddSingleton<IApplicationService, ApplicationService>();

代码设计服务生命周期

首先设计一些服务相关的操作接口

public interface IOperation
{
    Guid GetGuid();
}


public interface IOperationTransient : IOperation
{
}


public interface IOperationScoped : IOperation
{
}


public interface IOperationSingleton : IOperation
{      
}


public interface IOperationInstance : IOperation
{
}

其次对这些操作类予以实现并生成相关服务

/// <summary>
/// 常规服务
/// </summary>
public class Operation : IOperation
{
  private readonly Guid _guid;


  public Operation()
  {
       _guid = Guid.NewGuid();
   }


   public Operation(Guid guid)
   {
       _guid = guid == Guid.Empty? Guid.NewGuid() : guid;
   }


   public Guid GetGuid()
   {
       return _guid;
   }
}


/// <summary>
/// 瞬时服务
/// </summary>
public class OperationTransient : IOperationTransient
{
   private readonly Guid _guid;


   public OperationTransient()
   {
       _guid = Guid.NewGuid();
   }


   public OperationTransient(Guid guid)
   {
       _guid = guid == Guid.Empty ? Guid.NewGuid() : guid;
   }


   public Guid GetGuid()
   {
       return _guid;
   }
}


/// <summary>
/// 单次请求内服务固定
/// </summary>
public class OperationScoped : IOperationScoped
{
   private readonly Guid _guid;


   public OperationScoped()
   {
       _guid = Guid.NewGuid();
   }


   public OperationScoped(Guid guid)
   {
       _guid = guid == Guid.Empty ? Guid.NewGuid() : guid;
   }


   public Guid GetGuid()
   {
       return _guid;
   }
}


/// <summary>
/// 所有请求内固定服务
/// </summary>
public class OperationSingleton : IOperationSingleton
{
   private readonly Guid _guid;


   public OperationSingleton()
   {
       _guid = Guid.NewGuid();
   }


   public OperationSingleton(Guid guid)
   {
       _guid = guid == Guid.Empty ? Guid.NewGuid() : guid;
   }


   public Guid GetGuid()
   {
       return _guid;
   }
}


/// <summary>
/// 应用程序内固定服务
/// </summary>
public class OperationInstance : IOperationInstance
{
   private readonly Guid _guid;


    public OperationInstance()
    {
        _guid = Guid.NewGuid();
    }


    public OperationInstance(Guid guid)
    {
        _guid = guid == Guid.Empty ? Guid.NewGuid() : guid;
    }


    public Guid GetGuid()
    {
        return _guid;
    }
}

对基础服务的聚合接口，提供统一服务接口

KnockoutJS-模板绑定

Sat, 13 Oct 2018 10:00:00 +0800

对于knockoutJS来讲，模板绑定和Mapping插件绑定是十分重要的功能，虽然模板绑定在我工作中用的及其少，但模板绑定的重要性不可忽视，在其他前端框架中，如Angular、Vue等等，模板存在的意义十分重要，Mapping插件使得我们能够脱离手工绑定，及其方便我们快速绑定达到预期效果。

KnockoutJS模板绑定更多用法：https://knockoutjs.com/documentation/template-binding.html

模板绑定目的

在mvc的开发中，对于常用的一些独立的Html，习惯将它变成分布视图或是视图组件，以此来方便调用以及重用，同时也达到解耦效果，同样在前端开发中，对于部分重用度很高、复杂度高的UI、嵌套UI等这些部分，我们也可以设计成模板。

在knockoutJS中通过template绑定将模板绑定到预期DOM元素中，将模板所依赖的数据呈现。模板绑定对于构建嵌套结构的页面十分方便，默认情况， Knockout使用jquery.tmpl模板引擎，使用模板绑定时，需引用jquery.tmpl和jQuery框架，或者你也可以集成其它的模板引擎(需要了解Knockout 内部知识)。

模板语法：

${ someValue }
{{html someValue}}
{{if someCondition}}
{{else someCondition}}
{{each someArray}}

具体了解模板语法可以查看：http://www.php.cn/js-tutorial-383558.html

模板绑定应用

如果你仅仅是声明的字符串，KO将会使用它作为模板的ID去渲染。应用在模板上的数据是你当前的viewModel对象。

构建一个简单模板

<hr />
<label>标准模板</label>
<div data-bind="template: 'personTemplate'"></div>
<script id='personTemplate' type='text/html'>
 ${ name } 是 ${ age } 岁
 <button class="btn btn-primary" data-bind='click: makeOlder'>增长一岁</button>
</script>


@section Scripts{
 <script type='text/javascript'>
 var viewModel = {
 name: ko.observable('刺客'),
 age: ko.observable(20),
 makeOlder: function () {
 viewModel.age(viewModel.age() + 1);
 }
 };


 $(function () {
 ko.applyBindings(viewModel);
 })
 </script>
}

通过设计一个简单的模板，在viewModel中的name或age发生改变后，Knockout将自动重新render模板。在该例子里，每次点击按钮都会重新渲染该模板。

Jenkins集群搭建

Sat, 15 Sep 2018 10:00:00 +0800

Jenkins的目的是加快CI/CD的步伐，集群的搭建也不是必须的，当一台服务器的构建速度受到限制下，可以考虑使用主从并发构建，来加快构建速度。作为一款超级管家的角色，Jenkins的资料非常多，Jenkins资料地址。

配置Jenkins-Slave节点环境

要充当Jenkins从节点角色的主机需要满足两个条件：

需要安装Java运行环境
Master主机可免密登录

先完成第二个条件的设计，在Master主机免密登录到Slave主机中，在这篇文章中提到了ssh的配置 https://www.cnblogs.com/CKExp/p/9552272.html 便不再详细陈述。

生成SSH密钥，一路回车即可。

ssh-keygen

发送密钥到Slave主机,需要填写Slave主机登录密码。

ssh-copy-id root@118.126.xx.29

连接Slave主机,无需输入密码。

ssh root@118.126.xx.29

现在直接登录到了Slave主机上，开始安装Java运行环境，我的服务器系统为CentOS7.2版本。看一下Java的列表并检索Java1.8的列表（本地将安装JDK1.8）

yum list java*
yum list java-1.8*

开始安装。

yum install java-1.8.0-openjdk* -y

安装完毕查看Java版本

java -version

Jenkins中配置Slave从节点

选择左侧菜单中的系统管理，然后选择管理节点,开始新建节点。(系统管理->管理节点->新建节点)

根据以下配置要求进行相关信息填写：

开始信息的填写工作：

凭证配置：

完成后点击保存，开始进行手动验证从节点身份，有时会出现一些错误(不可避免，没有谁真的一次性就成功的)。

看到这个界面后，等待一会，耗时比较长，

将任务转移到Slave从节点上构建

新建一个Jenkins任务，填入相应的信息，Git地址、执行脚本、执行相关配置，选择从节点。

遇到的错误：

提示私钥密码验证失败。

[05/15/14 09:37:32] [SSH] Opening SSH connection to xxx.xxx.xxx.xxx:xxx.
ERROR: Server rejected the 1 private key(s) for jenkins (credentialId:7265ff8a-1515-4745-a174-e6f550630818/method:publickey)
[05/15/14 09:37:32] [SSH] Authentication failed.
hudson.AbortException: Authentication failed.
 at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:1143)
 at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:648)
 at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:642)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:701)
[05/15/14 09:37:32] [SSH] Connection closed.
[05/15/14 09:37:32] Launch failed - cleaning up connection

是由于在Master这边没有对私钥文件进行授权使用命令chmod 600 /root/.ssh/id_rsa

DotNet&NPOI处理Excel文件

Tue, 11 Sep 2018 10:00:00 +0800

NPOI作为开源免费的组件，功能强大，可用来读写Excel(兼容xls和xlsx两种版本)、Word、PPT文件。可是要让我们记住所有的操作，这便有点困难了，至此，总结一些在开发中常用的针对Excel的简单。NPOI官网地址

NPOI的安装

下载NPOI或是通过Nuget包加入进来，然后在代码中引用如下命名空间，然后开始读写Excel文件。

using NPOI.SS.UserModel;
using NPOI.XSSF.UserModel;
using NPOI.HSSF.UserModel;
using NPOI.SS.Util;

NPOI写入Excel文件

在NPOI中，使用HSSFWorkbook类类来处理xls结尾的Excel文件(版本在2003及以前)，XSSFWorkbook类来处理xlsx结尾的Excel文件(版本在2007及以后)，都继承自接口IWorkbook，我们可以使用IWorkbook来统一处理两种不同格式的Excel文件。

直接参考相关代码即可，对于合并单元格的跨行跨列操作，无需将被跨掉的行生成新行，合并单元格的信息是单独保存的。设置单元格样式时，请创建一个新的样式对象，不创建将使用默认的样式对象。

/// <summary>
/// Datable导出到Excel
/// </summary>
/// <returns></returns>
public static void DataTableToExcel()
{
    //一些已有数据信息
    bool fileSaved = false;
    SaveFileDialog saveDialog = new SaveFileDialog
    {
        DefaultExt = "xls",
        Filter = "Excel文件|*.xls",
        FileName = DateTime.Now.ToString("yyyyMMdd") + "-" + enterpriseTable.Rows[0]["名称"].ToString() + "委托书"
    };
    saveDialog.ShowDialog();
    string saveFileName = saveDialog.FileName;
    if (saveFileName.IndexOf(":") < 0) return; //被点了取消
    if (saveFileName != "")
    {
        try
        {
            IWorkbook workbook;
            string fileExt = System.IO.Path.GetExtension(saveFileName).ToLower();
            if (fileExt == ".xlsx")
            {
                workbook = new XSSFWorkbook();
            }
            else if (fileExt == ".xls")
            {
                workbook = new HSSFWorkbook();
            }
            else
            {
                return;
            }


            ISheet sheet = workbook.CreateSheet("Sheet1");


            sheet.AddMergedRegion(new CellRangeAddress(0, 3, 0, 9));//合并单元格
            IRow row = sheet.CreateRow(0);//创建首行
            ICell cell = row.CreateCell(0);//行中创建第一列
            cell.SetCellValue("标题");
            ICellStyle style = workbook.CreateCellStyle();//设置样式，创建新的style实例，脱离统一样式
            style.Alignment = NPOI.SS.UserModel.HorizontalAlignment.Center;//设置单元格的样式：水平对齐居中
            style.VerticalAlignment = NPOI.SS.UserModel.VerticalAlignment.Center;


            IFont font = workbook.CreateFont();//新建一个字体样式对象
            font.Boldweight = short.MaxValue; //设置字体加粗样式
            style.SetFont(font); //使用SetFont方法将字体样式添加到单元格样式中
            cell.CellStyle = style; //将新的样式赋给单元格


            sheet.AddMergedRegion(new CellRangeAddress(4, 4, 1, 4));
            sheet.AddMergedRegion(new CellRangeAddress(4, 4, 6, 9));
            row = sheet.CreateRow(4);
            cell = row.CreateCell(0);
            cell.SetCellValue("编号:");
            cell = row.CreateCell(1);
            cell.SetCellValue(planCode);
            cell = row.CreateCell(5);
            cell.SetCellValue("日期：");
            cell = row.CreateCell(6);
            cell.SetCellValue(taskPlantable.Rows[0]["编制日期"].ToString());


            sheet.AddMergedRegion(new CellRangeAddress(5, 5, 1, 4));
            sheet.AddMergedRegion(new CellRangeAddress(5, 5, 6, 9));
            row = sheet.CreateRow(5);
            cell = row.CreateCell(0);
            cell.SetCellValue("单位:");
            cell = row.CreateCell(1);
            cell.SetCellValue(enterpriseTable.Rows[0]["名称"].ToString());
            cell = row.CreateCell(5);
            cell.SetCellValue("联系人：");
            cell = row.CreateCell(6);
            cell.SetCellValue(enterpriseTable.Rows[0]["联系人"].ToString());


            sheet.AddMergedRegion(new CellRangeAddress(6, 6, 1, 4));
            sheet.AddMergedRegion(new CellRangeAddress(6, 6, 6, 9));
            row = sheet.CreateRow(6);
            cell = row.CreateCell(0);
            cell.SetCellValue("传真:");
            cell = row.CreateCell(1);
            cell.SetCellValue(enterpriseTable.Rows[0]["传真"].ToString());
            cell = row.CreateCell(5);
            cell.SetCellValue("联系电话：");
            cell = row.CreateCell(6);
            cell.SetCellValue(enterpriseTable.Rows[0]["电话"].ToString());


            sheet.AddMergedRegion(new CellRangeAddress(7, 7, 1, 9));
            row = sheet.CreateRow(7);
            cell = row.CreateCell(0);
            cell.SetCellValue("详细地址:");
            cell = row.CreateCell(1);
            cell.SetCellValue(enterpriseTable.Rows[0]["详细地址"].ToString());


            int index = 7;
            //数据
            for (int i = 0; i < taskProjectTable.Rows.Count; i++)
            {
                index++;
                sheet.AddMergedRegion(new CellRangeAddress(index, index, 1, 4));
                sheet.AddMergedRegion(new CellRangeAddress(index, index, 6, 9));
                row = sheet.CreateRow(index);
                cell = row.CreateCell(0);
                cell.SetCellValue("名称:");
                cell = row.CreateCell(1);
                cell.SetCellValue(taskProjectTable.Rows[i]["名称"].ToString());
                cell = row.CreateCell(5);
                cell.SetCellValue("类型:");
                cell = row.CreateCell(6);
                cell.SetCellValue(taskProjectTable.Rows[i]["项目类型"].ToString());


                index++;
                sheet.AddMergedRegion(new CellRangeAddress(index, index, 0, 2));
                sheet.AddMergedRegion(new CellRangeAddress(index, index, 3, 5));
                sheet.AddMergedRegion(new CellRangeAddress(index, index, 6, 9));
                row = sheet.CreateRow(index);
                cell = row.CreateCell(0);
                cell.SetCellValue("项目");
                cell = row.CreateCell(3);
                cell.SetCellValue("方法");
                cell = row.CreateCell(6);
                cell.SetCellValue("仪器");


                //获取数据信息
                DataTable taskDataTable = mysql.GetTableFromSQL(selstr.ToString());
                selstr.Clear();
                for (int j = 0; j < taskDataTable.Rows.Count; j++)
                {
                    index++;
                    sheet.AddMergedRegion(new CellRangeAddress(index, index, 0, 2));
                    sheet.AddMergedRegion(new CellRangeAddress(index, index, 3, 5));
                    sheet.AddMergedRegion(new CellRangeAddress(index, index, 6, 9));
                    row = sheet.CreateRow(index);
                    cell = row.CreateCell(0);
                    cell.SetCellValue(taskDataTable.Rows[j]["名称"].ToString());
                    cell = row.CreateCell(3);
                    cell.SetCellValue(taskDataTable.Rows[j]["方法"].ToString());
                    cell = row.CreateCell(6);
                    cell.SetCellValue(taskDataTable.Rows[j]["仪器型号"].ToString());
                }
            }


            //转为字节数组
            MemoryStream stream = new MemoryStream();
            workbook.Write(stream);
            var buf = stream.ToArray();


            //保存为Excel文件
            using (FileStream fs = new FileStream(saveDialog.FileName, FileMode.Create, FileAccess.Write))
            {
                fs.Write(buf, 0, buf.Length);
                fs.Flush();
            }
            fileSaved = true;
        }
        catch (Exception ex)
        {
            fileSaved = false;
            MessageBox.Show("导出文件时出错,文件可能正被打开！\n" + ex.Message);
        }
    }
    GC.Collect();//强行销毁


    if (fileSaved && File.Exists(saveFileName))
    {
        MessageBox.Show("导出成功！", "通知");
        Process.Start(saveFileName);
    }
    else
    {
        MessageBox.Show("导出失败！", "通知");
    }
}

NPOI读取Excel文件

打开指定Excel文件并读取文件中的内容，加入到DataTable中，或是加入到其它的数据载体中。

Docker Machine搭建并加入节点

Sat, 01 Sep 2018 10:00:00 +0800

对于集群服务器来讲，要在每台机器上手动安装Docker是一件及其痛苦的事情，还好有Docker Machine这一工具，Docker三剑客中的一角.

Docker Machine介绍

这个工具已经出了比较久了，Docker Machine官方介绍：https://docs.docker.com/v1.13/machine/overview/ ,按我的理解就是一个控制系的高手操作着地下一批人，犹如该图，面对不同的服务器，云、虚拟机、本地主机等。通过Docker Machine进行批量安装。

服务器环境介绍

当前服务器版本CentOS7.2 64bit，Docker版本1.13.1，Docker Machine版本0.10.0。

服务器列表：

Master:182.61.xxx.218 – A
Slave:106.12.xxx.4 –B
Slave:118.126.xxx.29 –C
Slave:123.207.xxx.233 –D

将通过服务器A完成在B、C和D上完成Docker环境的安装

完成Docker Machine搭建

首先我们在A服务器上安装Docker环境，安装过程可见：https://www.cnblogs.com/CKExp/p/8159269.html，在此直接开始Docker Machine的安装。

在服务器A上开始安装Docker Machine，输入以下命令从docker仓库中下载下来，并完成权限配置，注意我这里下载的版本是0.10.0，如果需要更高的版本呢下载可以选择其它版本下载

1 $ curl -L https://github.com/docker/machine/releases/download/v0.10.0/docker-machine-$(uname -s)-$(uname -m) >/tmp/docker-machine &&
2 chmod +x /tmp/docker-machine &&
3 sudo cp /tmp/docker-machine /usr/local/bin/docker-machine

搭建成功,查看服务器版本:

docker-machine -v

用Docker Machine配置子节点安装Docker engine

首先我们首先得保证两个服务器的正常通讯，因此先生成密钥对，保证免交互登录。

创建密钥对（在A主机操作），输入命令并一直回车

# ssh-keygen

拷贝公钥到B、C和D主机上,过程中需要确认连接、输入密码(直接登录目标主机的密码)等操作，正常进行即可。

# ssh-copy-id root@106.12.xxx.4

然后通过该命令连接是否可以正常登录到目标主机

# ssh root@106.12.xxx.4

接下来，可以依次将docker环境安装到各子节点上，通过docker-machine提供的命令create及其各种附带指定， -d命令指定了引用的驱动类型，我这全是Linux下服务器，直接用generic即可，如果是其它类型，可以看一下官网提供的驱动类型。

Docker中完成Jenkins的安装

Fri, 31 Aug 2018 10:00:00 +0800

去年就开始学习采用Docker+Jenkins+.Net Core搭建生成式流水线，一直拖到现在，也没有彻底的好好静下来去总结总结。趁着现在对自己的严格要求下，逐渐开始重视自我总结，以此来巩固逐渐失去的知识。

安装Docker

这里可以参考之前写过的一篇文章：https://www.cnblogs.com/CKExp/p/8159269.html 内容比较简单，但还算是能够实用，安装的Docker版本是1.13.1，服务器版本是CentOS7.2。

安装Jenkins

先说明一下，在Jenkins安装时，我们需要在里面配置号Docker Compose组件，以此来支撑我们在后面同时发布多个网站或服务。有关docker compose知识可以参见https://yeasy.gitbooks.io/docker_practice/content/swarm/

所以我们不直接拉取Jenkins镜像，通过Dockerfile的形式来拉取Jenkins镜像，并在容器内安装好Docker Compose组件。而不单独在宿主机上安装Docker Compose，尽管那样也没问题，只需将应用程序直接部署到宿主机上就行，但是就失去了我们想要设计成流水线的目的了。

先创建一个Jenkins文件夹并编写Dockerfile文件：

1 # cd /
2 # mkdir Jenkins
3 # cd Jenkins
4 # touch Dockerfile
5 # vim Dockerfile

Dockerfile文件内容：

FROM jenkins
USER root


#更新源并安装libltdl7
RUN apt-get update && apt-get install -y libltdl7
ARG dockerGid=999
RUN echo "docker:x:${dockerGid}:jenkins" >> /etc/group


# 安装 Docker-Compose
RUN curl -L https://github.com/docker/compose/releases/download/1.22.0/docker-compose-'uname -s'-'uname -m' -o /usr/local/bin/docker-compose
# 授权
RUN chmod +x /usr/local/bin/docker-compose

开始构建该镜像

KnockoutJS-绑定元素

Sun, 26 Aug 2018 10:00:00 +0800

工作变更，又走回了WPF，一个来月没有接触web开发了，之前的KnockoutJS却不想放弃，继续进行知识的巩固，下个月开始重新走回web开发之路，还是得用回一些习惯了的工具。本次开始接触各绑定元素功能、用法，这些绑定方式是在使用ko过程中用的最多的。

绑定元素在KnockoutJS中可以分为三大类

1、文本控制与显示隐藏

2、流程控制

3、配合表单使用

从个人使用过程中应用程度进行排序展示：

**value：**在DOM元素与viewModel对象的属性间建立桥梁，用户编辑控件时viewModel中对应属性值将自动更新，同样在更新了对应属性后，用户控件展示数据也将自动更新。常用于input、select、textarea等控件；
**text：**绑定到DOM元素上，将viewModel对象的属性的值展示在绑定元素上。常用于p、pre、label、span、th、td等控件使用；
click：绑定到DOM元素上添加事件句柄，当点击事件被触发时，执行我们定义好的JS函数。常用于button、input、a等控件使用。

click说明：在绑定函数时，可以指定任意函数，即在viewModel中声明的函数和在viewModel之外声明的函数都可被调用，同时在调用viewModel之内的函数时可以直接写函数名，而无需带上viewModel对象名。

**visible:**绑定到DOM元素上，该元素的隐藏或显示将有viewModel的属性状态、函数返回值或表达式来决定。

针对前四个绑定元素，简单演示一下功能：

Html:

<div>
    <label>公司名称</label>
    <input type="text" data-bind="value:unitName" /><br />
    <label>公司地址</label>
    <input type="text" data-bind="value:address" /><br />
    <p data-bind="text:'您的公司名称为:'+unitName()+'，公司地址是:'+address()+' .'"></p>
    <pre data-bind="text:'您的公司名称为:'+unitName()+'，公司地址是:'+address()+' .'"></pre>
    <label data-bind="text:'您的公司名称为:'+unitName()+'，公司地址是:'+address()+' .'"></label><br />
    <span data-bind="text:'您的公司名称为:'+unitName()+'，公司地址是:'+address()+' .'"></span><br />
    <table>
        <tr>
            <th data-bind="text:unitName"></th>
        </tr>
        <tr>
            <td data-bind="text:address"></td>
        </tr>
    </table>
    <div data-bind="visible:visibleButton">
        <button data-bind="click: updateUnitName">修改公司名称为中部星城科技</button><br />
        <button data-bind="click: updateAddress">修改公司地址为湖南长沙雨花区</button>
    </div>
    <div>
        <button data-bind="click:function(){viewModel.visibleButton(false);}">隐藏上面两个按钮</button>
    </div>
</div>

JS代码:

<script type="text/javascript">
    var viewModel = {
        //value、text
        unitName: ko.observable(""),
        address: ko.observable(""),


        //click
        //viewModel内JS函数
        updateAddress: function () {
            this.address("湖南长沙雨花区");
        },


        //visible
        visibleButton: ko.observable(true),
    };


    //任意JS函数
    function updateUnitName() {
        viewModel.unitName("中部星城科技");
    }


    $(function () {
        ko.applyBindings(viewModel);//完成绑定
    });
</script>

动画效果图：

AspNet Core WebApi中接入Swagger组件(初级)

Sat, 18 Aug 2018 10:00:00 +0800

开发WebApi时通常需要为调用我们Api的客户端提供说明文档。Swagger便是为此而存在的,能够提供在线调用、调试的功能和API文档界面。

环境介绍：Asp.Net Core WebApi + Swagger。

加入Swagger组件

Swashbuckle.AspNetCore 中分为3个组件。

Package	Description
Swashbuckle.AspNetCore.Swagger	Exposes SwaggerDocument objects as a JSON API. It expects an implementation of ISwaggerProvider to be registered which it queries to retrieve Swagger document(s) before returning as serialized JSON
Swashbuckle.AspNetCore.SwaggerGen	Injects an implementation of ISwaggerProvider that can be used by the above component. This particular implementation automatically generates SwaggerDocument(s) from your routes, controllers and models
Swashbuckle.AspNetCore.SwaggerUI	Exposes an embedded version of the swagger-ui. You specify the API endpoints where it can obtain Swagger JSON and it uses them to power interactive docs for your API、

安装Swashbuckle.AspNetCore，在Nuget中搜索或是包管理器下输入命令都可，找到这个包，安装，其中有三个小弟是三个不同的组件，在第一个中都集成了。

ABP框架开发-连接Mysql

Thu, 09 Aug 2018 10:00:00 +0800

开始想用Abp框架来搭建公司的新项目，虽然一切还没有定数，但是兵马未动，粮草先行，我先尝试一下整个过程，才能够更好的去争取机会。

此次技术选型:Abp(Asp.Net core mvc)+mysql(8.0)+docker

Abp官网地址：https://aspnetboilerplate.com/

Nuget中安装mysql相关包，oracle公司提供的mysql包用起来还有问题，所以现在都是用的第三方的mysql包。

pomelo.entityframeworkcore.mysql
pomelo.entityframeworkcore.mysql.design

在EntityFrameworkCore层中找到XXDbContextConfigurer，修改DbContext中数据库配置，默认使用的SqlServer，修改为mysql。

修改连接字符串，在Web.Host或是Web.MVC下找到appsetting.json文件并修改其中的连接字符串。

 "Default": "Server=xxx.xxx.xxx.xxx; Database=surrounddb;charset=utf8;uid=root;pwd=123456;"

我直接在服务器中的Docker下安装了一个mysql数据库，因此在开发环境下也将直接使用该数据库。

开始更新数据库，可将EntityFrameworkCore层下的Migrations文件夹删掉不影响,其中的是该版本历史过程中数据库迁移所带来的,于我们而言不重要了。

在程序包管理器控制台下选中EntityFrameworkCore，并开始输入命令

 PM>Add-Migration name(取一个本次更新的名称)

提示信息：To undo this action, use Remove-Migration.

 PM>Update-Database

没有差错下将会提示如下：提示信息：Applying migration ‘20180809141445_InitAll’. Done.

启动网站，成功打开并连接，如有表结构变化，更新数据库，只需再次运行之前两行命令即可。

注意：

1、我的mysql数据库版本已高于5.7，在mysql5.7时会报一些错误，诸如：Specified key was too long; max key length is 767 bytes之类的.

是由于该版本的mysql使用的编码方式不同，选择提升版本、通过修改mysql的编码方式解决(https://blog.csdn.net/NikoZhao/article/details/79521812)

2、连接字符串中如果加入了Ssl=None;将会出错，去掉即可。

2018-08-09，望技术有成后能回来看见自己的脚步。

KnockoutJS-快速入门

Sat, 14 Jul 2018 10:00:00 +0800

虽然在WPF中接触过MVVM模式，可是刚开始在Web中接触到Knockout.JS让我大吃一惊，简化了好多工作量，原来可能需要一大堆的JS脚本完成的工作量，被释放许多。接触KnockoutJS一年多了，在好多个项目中也用到过，虽然每个项目中都有点重复造轮子的滋味，但是不得不说，越来越喜欢用KO完成前端的一些工作，虽然现在有许多流行的MVVM/MVC前端框架，如Angular、Vue、React等等，接触过Vue，简单用过一次，接触不深，不敢谈论，也就带过吧。工作之余，开始总结自己在使用的工具、框架上用到的，体会到的感受。

简单例子

先来看个最简单ko所带来的效果：

看看代码是如何简洁设计的：

<div>
    <label>公司名称</label>
    <input type="text" data-bind="value:unitName" /><br />
    <label>公司地址</label>
    <input type="text" data-bind="value:address" />
    <p data-bind="text:'您的公司名称为:'+unitName()+'，公司地址是:'+address()+' .'"></p>
</div>


@section Scripts{
    <script type="text/javascript">
        var viewModel = {
            unitName: ko.observable(''),
            address: ko.observable(''),
        };
        $(function () {
            ko.applyBindings(viewModel);//完成绑定
        });
    </script>
}

概念介绍

knockout.JS利用的是MVVM模式，不依赖任何第三方的、纯Javascript编写的UI类库。官网地址：http://knockoutjs.com/

Model-View-View Model (MVVM) 是一种创建用户界面的设计模式。描述的是如何将复杂的UI用户界面分成3个部分：

Model：后台模型对象，存储着数据和操作，独立于前端UI的存在，与具体业务打交道。
ViewModel：前台数据展示，通常是用于对外交互的，ViewModel有两种不同的使用场景，一种是后台对外的ViewModel用于对外交互时接收的对象属于服务器端ViewModel，一种是前台Javscript对象在前台的数据交互模型.如ko中的ViewModel,当然这两种常常是互相转换的。
View：视图页面，用户能够见到的交互页面，存放着与ViewModel交互的UI，输入数据或操作对象完成对ViewModel的更新，

Knockout有着三大核心功能：
监控属性（Observables）和依赖跟踪（Dependency tracking）
声明式绑定（Declarative bindings）

AspNet Core中利用Seq组件展示结构化日志功能

Sat, 30 Jun 2018 10:00:00 +0800

在一次.Net Core小项目的开发中，掌握的不够深入，对日志记录并没有好好利用，以至于一出现异常问题，都得跑动服务器上查看，那时一度怀疑自己肯定没学好，不然这一块日志不可能需要自己扒服务器日志来查看，果然，很多东西没掌握，至此，花点时间看了下日志的相关操作。利用日志服务来查看日志数据。

本文地址：https://www.cnblogs.com/CKExp/p/9246788.html

本文Demo的地址：https://gitee.com/530521314/LogPanel.git

日志记录的原则

日志是为了方便我们观察应用程序是否正常运行，也是当运行不正常是，能够快速找到出现问题，定位问题的方式。

有几条日志记录原则是我们大多都得遵循的：

日志记录清晰，内容得让我们能够知道应用程序运行正常或运行不正常下能够有关键信息指明哪里出问题了。
不要过度记录，一些场景下我们需要预判是否需要记录日志信息，我们能够控制日志记录的数量，同样，日志内容，要精简记录，无关紧要的文字，废话等无需加入。
控制日志记录级别，或许在一个日志级别下记录了很多信息，可是其中的部分信息才是最为重要的，当调高一个记录级别，这部分最为重要的信息就展示出来了，那就直接调高级别吧。
隐私保护，日志虽然是让开发运维人员看到，可是我们也不能所有信息都记录下来，用户的隐私信息我们得保护好。

内置日志组件

Asp.Net Core中内置了日志组件，功能也很强大，首先来个简单示例：

直接使用内置日志功能，无需在startup中加入另外的代码。

private readonly ILogger<HomeController> _logger;


public HomeController(ILogger<HomeController> logger)
{
    _logger = logger;
}


public IActionResult Index()
{
    Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
    _logger.LogDebug($"开始监控整个网站的日志信息_{DateTime.Now}");
    //_logger.LogError($"开始监控整个网站的日志信息Error_{DateTime.Now}");
    return View();
}

在调试框下看到输出的日志信息。开始控制日志记录级别：

在StartUp下,对内置日志组件做一些处理，在配置文件中将日志记录的级别提高到Information级别：

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    //默认日志功能
    loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    loggerFactory.AddDebug();
    //loggerFactory.AddSerilog();


    if (env.IsDevelopment())
    {
        app.UseBrowserLink();
        app.UseDeveloperExceptionPage();//更多错误信息的开发者异常详情页
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
    }


    app.UseStaticFiles();


    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

appsetting.json文件中,将LogLevel的默认级别设为Information，这样一来在之前的示例中_logger.LogDebug将失去作用。

利用Bootstrap Paginator插件和KnockoutJS完成分页功能

Sun, 24 Jun 2018 10:00:00 +0800

在最近一个项目中，需要结合一堆条件查询并对查询的结果数据完成一个简单分页功能，可是做着做着，自己的思路越来越模糊，做到心态崩溃！！！哈哈,特此花点时间重新总结，并从最简单的分页，然后向多条件查询分页慢慢过渡，或许有人觉得这个很简单(可以绕道啦，哈哈)，却是对基础知识的一次学习过程。

Demo地址：https://gitee.com/530521314/Partner.TreasureChest/tree/master/Pagination/

本文地址：https://www.cnblogs.com/CKExp/p/9218904.html

环境介绍

分页功能很多已有的很完美的插件或是第三方应用包都能够完美实现，我在此利用了一些前端插件来完成分页功能。

前端的Bootstrap Paginator插件完成前端分页数字之类的切换展示；

利用knockout.js插件完成分页数据的绑定；

在后端，利用asp.net core mvc 完成分页信息的接收和处理工作。

简单分页

完成对已有数据的分页功能，不带条件查询。

首先，一上来便是完成数据绑定工作：

bookList: ko.mapping.fromJS(@Html.Raw(Newtonsoft.Json.JsonConvert.SerializeObject(Model))),//展示数据
pageEntity: ko.mapping.fromJS(@Html.Raw(Newtonsoft.Json.JsonConvert.SerializeObject(new PageRequestViewModel()))),//分页信息

页面刚展示的时候得有分页数据吧，可以在当页面展示的时候，数据也带过来了，也可以页面展示后，再通过ajax去后台调用，我选择后者。在页面启动时，调用该函数完成初始化页面数据。

getBookData: function () {
 var pageEntity = ko.mapping.toJS(viewModel.pageEntity);
 $.ajax({
 url: '@Url.Action("SampleGetData")',
 type: 'POST',
 dataType: 'json',
 data: pageEntity,
 success: function (result) {
 ko.mapping.fromJS(result.data, viewModel.bookList);
 options.totalPages = result.totalCount > 0 ? result.totalCount % options.numberOfPages == 0 ?
 result.totalCount / options.numberOfPages : (result.totalCount / options.numberOfPages) + 1 : 1;
 $('#pagination').bootstrapPaginator(options);
 }
 });
 }

分页信息(当前页面，页面展示数据条数)带过去，后台根据分页信息完成数据查询，并获得总的记录条数用于前端页面计算总页数。

[HttpPost]
public IActionResult SampleGetData(PageRequestViewModel pageEntity)
{
 var bookList = PageDataSeed.GetPageDataList()
 .Skip((pageEntity.PageIndex - 1) * pageEntity.PageSize)
 .Take(pageEntity.PageSize);


 var pageResultViewModel = new PageResultViewModel<Book>()
 {
 PageIndex = pageEntity.PageIndex,
 PageSize = pageEntity.PageSize,
 TotalCount = PageDataSeed.GetPageDataList().Count(),
 Data = bookList
 };


 return Json(pageResultViewModel);
}

根据分页信息查询也就搞定了，当点击底部的页面码的时候得改变当前分页信息，然后要切换当前分页信息所对应的数据出来，在Bootstrap paginator插件中，点击页面码有一个函数onPageClicked，点击具体的某一页后，根据参数page获得页面，改变当前展示的页面码数字，并对分页信息修改，然后再次调用ajax获得新数据。

图片在线裁剪和图片上传总结

Sat, 31 Mar 2018 10:00:00 +0800

上周需要做一个图片上传并且将上传的图片在线可以裁剪展示,觉得这个功能很有用，但是找参考资料的时候却并不是很多，因此来将我用到的总结总结，也让有需要的博友们直接借鉴。

环境介绍

asp.net mvc网站
- 用到的前端插件是JCrop和Bootstrap-fileinput，在后端用框架自带的一些类库进行处理即可。
- JCrop插件是用来裁剪图片的，页面上裁剪就是保存裁剪的位置信息，然后将位置信息转给后台在后台进行实际图片裁剪功能。插件地址：http://code.ciaoca.com/jquery/jcrop/demo/
- Bootstrap-fileinput插件是Bootstrap下的文件上传的插件，功能强大，我将依靠这个完成文件的上传，当然也能够使用其他的文件上传工具。插件地址：http://plugins.krajee.com/file-input
- 文件上传后页面上展示的图片是以Data URI Scheme方式进行展示的。Data URI Scheme知识点：https://blog.csdn.net/aoshilang2249/article/details/51009947
asp.net core mvc网站，前端插件不变，但是在后端不能够使用自带类库了，core下面的图片处理相关的类库还没有完全移植过来，只能够借用第三方类库SixLabors.ImageSharp。

快速浏览

git地址：https://gitee.com/530521314/TailorImage.git

前端页面代码

@{
    ViewBag.Title = "文件上传";
}


<link href="@Url.Content("~/Content/Jcrop/jquery.Jcrop.css")" rel="stylesheet" />
<link href="@Url.Content("~/Content/bootstrap-fileinput/fileinput.css")" rel="stylesheet" />


<br />
<button class="btn btn-primary" data-toggle="modal" data-target="#myModal">头像</button>
<div class="modal fade" id="myModal" tabindex="-1" role="dialog" aria-labelledby="myModalLabel" aria-hidden="true">
    <div class="modal-dialog">
        <div class="modal-content">
            <div class="modal-header">
                <button type="button" class="close" data-dismiss="modal" aria-hidden="true">×</button>
                <h4 class="modal-title" id="myModalLabel">图片上传</h4>
            </div>
            <div class="modal-body">
                <div class="row">
                    <div class="col-md-6" style="width: 300px;">
                        <img id="cut-img" class="thumbnail" style="width: 300px;height:300px;" src="~/Content/defaultAvatar.jpg"><br />
                    </div>
                    <div class="col-md-5">
                        <input type="file" name="txt_file" id="txt_file" multiple class="file-loading" /><br />
                        <h4>图片说明：</h4>
                        <p>1、图片格式需要jpg、gif、png为后缀名.</p>
                        <p>2、图片可以在线裁剪大小,以裁剪后为最终结果.</p>
                        <p>3、图片上传完毕即可关闭窗口.</p>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>




@section scripts{
    <script src="@Url.Content("~/Scripts/Jcrop/jquery.Jcrop.js")"></script>
    <script src="@Url.Content("~/Scripts/bootstrap-fileinput/fileinput.js")"></script>
    <script src="@Url.Content("~/Scripts/bootstrap-fileinput/zh.js")"></script>
    <script type="text/javascript">


        //http://code.ciaoca.com/jquery/jcrop/
        //http://code.ciaoca.com/jquery/jcrop/demo/animation
        //http://plugins.krajee.com/file-input
        //http://plugins.krajee.com/file-advanced-usage-demo#advanced-example-5


        var tailorInfo = "";


        //初始化fileinput
        function FileInput() {
            var oFile = new Object();


            oFile.Init = function (ctrlName, uploadUrl) {
                var control = $('#' + ctrlName);
                //初始化上传控件的样式
                control.fileinput({
                    language: 'zh', //设置语言
                    browseLabel: '选择',
                    browseIcon: "<i class=\"glyphicon glyphicon-picture\"></i> ",
                    browseClass: "btn btn-primary", //按钮样式
                    uploadUrl: uploadUrl, //上传的地址
                    allowedFileExtensions: ['jpg', 'gif', 'png'],//接收的文件后缀
                    showUpload: true, //是否显示上传按钮
                    showCaption: false,//是否显示标题
                    showPreview: false,//隐藏预览
                    dropZoneEnabled: false,//是否显示拖拽区域
                    uploadAsync: true,//采用异步
                    autoReplace: true,
                    //minImageWidth: 50,
                    //minImageHeight: 50,
                    //maxImageWidth: 1000,
                    //maxImageHeight: 1000,
                    //maxFileSize: 0,//单位为kb，如果为0表示不限制文件大小
                    //minFileCount: 0,
                    maxFileCount: 1, //表示允许同时上传的最大文件个数
                    enctype: 'multipart/form-data',
                    validateInitialCount: true,
                    previewFileIcon: "<i class='glyphicon glyphicon-king'></i>",
                    msgFilesTooMany: "选择上传的文件数量({n}) 超过允许的最大数值{m}！",
                    uploadExtraData: function () {
                        return { "tailorInfo": tailorInfo }
                    }
                });
            }


            return oFile;
        };


        function PageInit() {
            var jcorp = null;
            var _this = this;
            var fileInput = new FileInput();
            fileInput.Init("txt_file", "@Url.Action("UpLoadFile")");
            var input = $('#txt_file');


            //图片上传完成后
            input.on("fileuploaded", function (event, data, previewId, index) {
                if (data.response.success) {
                    jcorp.destroy();


                    $('#cut-img').attr('src', data.response.newImage);//Data URI Scheme形式
                    //$('#cut-img').attr('src', data.response.newImage + "?t=" + Math.random());//加尾巴解决缓存问题
                }
                alert(data.response.message);
            });


            //选择图片后触发
            input.on('change', function (event, data, previewId, index) {
                var img = $('#cut-img');
                if (input[0].files && input[0].files[0]) {
                    var reader = new FileReader();
                    reader.readAsDataURL(input[0].files[0]);
                    reader.onload = function (e) {
                        img.removeAttr('src');
                        img.attr('src', e.target.result);
                        img.Jcrop({
                            setSelect: [0, 0, 260, 290],
                            handleSize: 10,
                            aspectRatio: 1,//选框宽高比
                            bgFade: false,
                            bgColor: 'black',
                            bgOpacity: 0.3,
                            onSelect: updateCords
                        }, function () {
                            jcorp = this;
                        });
                    };
                    if (jcorp != undefined) {
                        jcorp.destroy();
                    }
                }
                function updateCords(obj) {
                    tailorInfo = JSON.stringify({ "PictureWidth": $('.jcrop-holder').css('width'), "PictureHeight": $('.jcrop-holder').css('height'), "CoordinateX": obj.x, "CoordinateY": obj.y, "CoordinateWidth": obj.w, "CoordinateHeight": obj.h });
                    console.log(tailorInfo);
                }
            });


            //上传出现错误
            input.on('fileuploaderror', function (event, data, msg) {
                alert(msg);


                //jcorp.destroy();
                //$('#cut-img').attr('src', '/Content/defaultAvatar.jpg');
                return false;
            });


            //移除图片
            input.on('fileclear', function (event) {
                console.log("fileclear");


                jcorp.destroy();
                $('#cut-img').attr('src', '/Content/defaultAvatar.jpg');
            });
        };


        $(function () {
            PageInit();
        });
    </script>
}

后端控制器代码

public class FileInputController : Controller
{
    [HttpGet]
    public ActionResult UpLoadFile()
    {
        return View();
    }


    [HttpPost]
    public ActionResult UpLoadFile(string tailorInfo)
    {
        var success = false;
        var message = string.Empty;
        var newImage = string.Empty;
        try
        {
            var tailorInfoEntity = JsonConvert.DeserializeObject<TailorInfo>(tailorInfo);
            tailorInfoEntity.PictureWidth = tailorInfoEntity.PictureWidth.Replace("px", "");
            tailorInfoEntity.PictureHeight = tailorInfoEntity.PictureHeight.Replace("px", "");


            var file = HttpContext.Request.Files[0];
            if (file != null && file.ContentLength != 0)
            {
                newImage = ImageHelper.TailorImage(file.InputStream, tailorInfoEntity);
                success = true;
                message = "保存成功";
            }
        }
        catch (Exception ex)
        {
            message = "保存失败" + ex.Message;
        }


        return Json(new { success = success, message = message, newImage = newImage });
    }
}

裁剪信息类

/// <summary>
/// 前端裁剪信息及前端图片展示规格
/// </summary>
public class TailorInfo
{
    public string PictureWidth { get; set; }
    public string PictureHeight { get; set; }
    public int CoordinateX { get; set; }
    public int CoordinateY { get; set; }
    public int CoordinateWidth { get; set; }
    public int CoordinateHeight { get; set; }
}

图片辅助类

/// <summary>
/// 图片处理
/// </summary>
public static class ImageHelper
{
    /// <summary>
    /// 图片按照实际比例放大
    /// </summary>
    /// <param name="content"></param>
    /// <param name="tailorInfo"></param>
    /// <returns></returns>
    public static string TailorImage(Stream content, TailorInfo tailorInfo)
    {
        var scaleWidth = Convert.ToInt16(tailorInfo.PictureWidth);
        var scaleHeight = Convert.ToInt16(tailorInfo.PictureHeight);


        Bitmap sourceBitmap = new Bitmap(content);
        double scaleWidthPercent = Convert.ToDouble(sourceBitmap.Width) / scaleWidth;
        double scaleHeightPercent = Convert.ToDouble(sourceBitmap.Height) / scaleHeight;


        double realX = scaleWidthPercent * tailorInfo.CoordinateX;
        double realY = scaleHeightPercent * tailorInfo.CoordinateY;
        double realWidth = scaleWidthPercent * tailorInfo.CoordinateWidth;
        double realHeight = scaleHeightPercent * tailorInfo.CoordinateHeight;


        return CropImage(content, (int)realX, (int)realY, (int)realWidth, (int)realHeight);
    }


    /// <summary>
    /// 生成新图片
    /// </summary>
    /// <param name="content"></param>
    /// <param name="x"></param>
    /// <param name="y"></param>
    /// <param name="cropWidth"></param>
    /// <param name="cropHeight"></param>
    /// <returns></returns>
    public static string CropImage(byte[] content, int x, int y, int cropWidth, int cropHeight)
    {
        using (MemoryStream stream = new MemoryStream(content))
        {
            return CropImage(stream, x, y, cropWidth, cropHeight);
        }
    }


    /// <summary>
    /// 生成新图片
    /// </summary>
    /// <param name="content"></param>
    /// <param name="x"></param>
    /// <param name="y"></param>
    /// <param name="cropWidth"></param>
    /// <param name="cropHeight"></param>
    /// <returns></returns>
    public static string CropImage(Stream content, int x, int y, int cropWidth, int cropHeight)
    {
        using (Bitmap sourceBitmap = new Bitmap(content))
        {
            Bitmap bitSource = new Bitmap(sourceBitmap, sourceBitmap.Width, sourceBitmap.Height);
            Rectangle cropRect = new Rectangle(x, y, cropWidth, cropHeight);
            using (Bitmap newBitMap = new Bitmap(cropWidth, cropHeight))
            {
                newBitMap.SetResolution(sourceBitmap.HorizontalResolution, sourceBitmap.VerticalResolution);
                using (Graphics g = Graphics.FromImage(newBitMap))
                {
                    g.InterpolationMode = InterpolationMode.HighQualityBicubic;
                    g.SmoothingMode = SmoothingMode.HighQuality;
                    g.PixelOffsetMode = PixelOffsetMode.HighQuality;
                    g.CompositingQuality = CompositingQuality.HighQuality;
                    g.DrawImage(bitSource, new Rectangle(0, 0, newBitMap.Width, newBitMap.Height), cropRect, GraphicsUnit.Pixel);
                    return BitmapToBytes(newBitMap);
                }
            }
        }
    }


    /// <summary>
    /// 图片转到byte数组
    /// </summary>
    /// <param name="source"></param>
    /// <returns></returns>
    public static string BitmapToBytes(Bitmap source)
    {
        ImageCodecInfo codec = ImageCodecInfo.GetImageEncoders()[4];
        EncoderParameters parameters = new EncoderParameters(1);
        parameters.Param[0] = new EncoderParameter(Encoder.Quality, 100L);
        using (MemoryStream tmpStream = new MemoryStream())
        {
            source.Save(tmpStream, codec, parameters);
            byte[] data = new byte[tmpStream.Length];
            tmpStream.Seek(0, SeekOrigin.Begin);
            tmpStream.Read(data, 0, (int)tmpStream.Length);
            return SaveImageToLocal(data);
        }
    }


    /// <summary>
    /// 存储图片到本地文件系统
    /// </summary>
    /// <param name="binary"></param>
    public static string SaveImageToLocal(byte[] binary)
    {
        //根据用户信息生成图片名 todo


        var path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"Content\avatar.png");
        File.WriteAllBytes(path, binary);
        return "data:images/png;base64," + Convert.ToBase64String(binary);//Data URI Scheme形式
        //return @"/Content/avatar.png";//Url形式
    }
}

具体步骤

引用前端插件

加入JCrop插件，在官网下载或是git上下载均可,引用这两个文件即可，注意引用地址正确哈。

DotNet Core和Jexus配置HTTPS服务

Sun, 25 Feb 2018 10:00:00 +0800

花了几天时间，看了好多篇博客，终于搞定了网站的HTTPS服务，借此写篇博客，来让有需要的朋友少走弯路。

环境介绍

Linux下在Docker容器中部署好了一个网站，该网站需要通过外部提供程序访问微软的登录平台，利用的是OAuth2.0协议，因此要求必须要使用SSL服务，也使得网站必须要加入HTTPS服务。
容器外，宿主机上通过jexus做端口转发。(本没打算用到jexus,但是看到情形不对，还是必须把它拉入进来)
HTTPS服务需要证书，通过在腾讯云上申请免费证书https://console.cloud.tencent.com/ssl，一天之内便可申请到，注意了！！！，假如说使用的和我一样也是用的jexus，而腾讯云提供的证书下载包里面没有jexus，只有IIS、Nginx、Apache..等等。

我们是可以直接利用Nginx的两个文件。第一个是crt文件，第二个是key文件**。**

假如说你需要pfx结尾的文件那么可以通过这两个文件进行合成生成pfx文件可以通过命令:

openssl pkcs12 -export -out server.pfx -inkey server.key -in server.crt

将其中文件名更改为你的文件名即可。又或者度娘上也有将内容粘贴进去然后自动生成的网站，不要敲命令的，这就不再提供网站了。

全配置

首先，我想说下，我在jexus中配置了HTTPS服务，在Docker容器中运行的网站中也配置好了HTTPS服务。如同此图：

可能有人会想，为什么都要配置，只配置jexus就足够了啊。当然，配置jexus是足够了，但是我的网站里面如果需要调用比如OAuth2.0协议支持的网站时，回掉地址总是会是用的HTTP协议，开发环境下没问题，但是一旦弄上域名或是IP地址访问，那么生成的就是HTTP的协议了。

具体就是在此处.我通过配置好了微软的外部提供程序，当点击按钮后将跳转到微软登录页面：

跳转后，当前登录页面的url中写明了一些参数是我们想要的，比如redirect_url，此时我已经配置好了网站上的HTTPS协议，在没有配上时，该处的redirect_url一直都是HTTP的

好了，开始配置HTTPS服务：

在.Net Core中配置HTTPS协议

首先，这里可能要搞清楚一下，jexus和网站之间的请求转发，这也是我想弄清楚的一个问题，jexus端口转发请求的时候是不是还是HTTPS协议的，还是说只是请求转发，到了网站中又变成了HTTP了。就如这个模型,在jexus转发之后，进入kestrel后是HTTP协议的还是HTTPS协议的？希望各位博友帮忙，我没有找到参考资料。

我能做的就是在我尝试在kestrel中不配置HTTPS协议下，访问网站虽然也是能够成功的，但是当通过微软的第三方登录成功后回调地址访问网站时，便会是使用的HTTP协议，也就会出问题，与OAuth要求使用SSL的服务必须使用HTTPS协议相矛盾，也就促使着我必须要在kestrel中配置好HTTPS协议。具体配置如下：

在Program.cs文件中,加入前面所合成的pfx文件，即可，这种情形下，要求我的每一个容器中的运行的网站都需要使用证书了。同时注意，在此处不能够使用.UseUrls(“https:”//:443")来设置HTTPS服务，在没有配置.UseKestrel()下是会报错的，望注意！。

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Logging;
using Microsoft.AspNetCore.Server.Kestrel.Core;
using System.Security.Cryptography.X509Certificates;
using System.Net;
using Identity.Api.Web.Core;


namespace Identity.Api
{
 public class Program
 {
 public static void Main(string[] args)
 {
 BuildWebHost(args).Run();
 }


 public static IWebHost BuildWebHost(string[] args) =>
 WebHost.CreateDefaultBuilder(args)
 //.UseJexusIntegration()
 .UseKestrel(options =>
 {
 options.Listen(IPAddress.Any, 1101, listenOptions =>
 {
 var certificate = new X509Certificate2("hdshopserver.pfx", "你的证书密码");
 listenOptions.UseHttps(certificate);
 });
 })
 .UseStartup<Startup>()
 .Build();
 }
}

在jexus上配置HTTPS协议（假如说用的不是jexus或是没有用到jexus，则可跳过此处）

首先，通过命令查看到我的jexus版本是5.8.3，是支持HTTPS的了。

DotNet Core&Docker&Jexus的实践

Tue, 13 Feb 2018 10:00:00 +0800

本文基于上次尝试之后的进一步尝试，加入Docker容器、编写Dockerfile,并且jexus结合Docker的使用，总结下自己的个人感想。

环境介绍

当前的场景有两种方式将Demo实现运行，一种是我将Asp.Net Core项目通过自侦听方式启动，然后外网正常访问，第二种通过功能强大的jexus作为代理，将项目发布后部署到jexus配置下，通过修改配置文件，通过jexus进行反向代理，此时项目本身可以不需要自侦听方式。目前是直接在主机下进行的，并没有加入到Docker容器中。

Docker中启动网站（暂未加入Dockerfile）

首先，摆在面前的就有一个问题，我是直接根据镜像建立容器，然后在容器中安装Git获取项目、安装jexus部署项目、安装vim修改配置文件，还是直接获取项目后自启动侦听呢。不得不承认这两种情形都是很糟糕的，或许来说功能实现了，但是这个实现的过程是很不值得的，恰巧，我就完完全全走了一遍。

加入Docker容器，容器中加入jexus

通过之前的一篇文章http://www.cnblogs.com/CKExp/p/8159269.html不难将Docker环境搭建起来，此处将不再制造轮子。一步一步分析，首先在容器中安装Git，也就意味着假如我要操作上百个容器那不是意味着我要安装上百次Git，同理jexus，也同理Vim，这是很不值得的，然后我在想，能否将这些个软件写到Dockerfile中呢，可以，但谁又会这么去做呢。不扯远了，单讲讲网站启动，我在容器中通过将网站发布后，重新启动jexus，通过外网访问（ip:端口），可以访问的通，还是很开心的，至少没出什么问题。

dotnet publish -o /var/www/HDShop
sh /usr/jexus/jws restart

注意，这里的端口已经有了映射关系，我在建立容器的时候就已经指定了容器对外访问端口，所以网站的默认端口已经不合适了，我直接在Programcs中加入了UseUrls(“http://*:3456”),容器对外访问端口是2345.

public static IWebHost BuildWebHost(string[] args) =>
 WebHost.CreateDefaultBuilder(args)
 .UseUrls("http://*:3456")
 .UseStartup<Startup>()
 .Build();

也可以通过curl命令（curl ip:端口）查看能否正常访问，将返回网站页面信息。

加入Docker容器，容器中网站启动自侦听

Demo获取完毕，直接通过自侦听方式启动网站dotnet run 也是可以正常访问的。通过一组实验之后，我得到了一组信息，包含了我们想要的结果：

2345：3456 -> 此方式为主机下项目直接共享到容器中，主机可改变，双方可见，容器改变，仅容器可见，对主机文件并无影响。采用镜像为dotnet ,并未构造自身的镜像

总结：不采用jexus仍然能够正常运行，jexus只是加强了更多的功能。既然有无jexus对我容器内部的网站启动作用不大，那么我就可以考虑在Docker中除非有特殊情况，否则我是坚决不会将jexus加入到Docker中。当然，主机上的jexus功能还是需要留着的，只是容器中jexus存在的必要性就要考虑了。

直接通过主机上的Git获取项目

通过指令将项目共享到容器中，主机上的直接修改将影响中容器内部的修改，而容器中对文件的修改却是隔离主机的，不对实际的文件进行改变。

docker run -dit -p 2345:3456 --privileged=true -v /HDShop:/HDShop microsoft/dotnet

这样一来，我在主机上获得项目，直接在容器中进行编译，运行，是不错的。那么容器中Git存在的必要性被我否决掉了。通过实际操作，这是很可行的，外网也能正常访问。甚至是说，我接下来的所有操作，都将依赖这种形式。

同样来讲，我在主机上直接修改，容器中生效，那么容器中在去安装Vim也就不必要了，除非来说容器中的文件要相对主机上的要做一些改动，那么便下载一个Vim把，毕竟容器中可没有Vim。

敲vim命令时提示说：vim: command not found，这个时候就需要安装vim，可是当你敲apt-get install vim命令时，提示：

Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package vim

这时候需要敲：apt-get update，这个命令的作用是：同步 /etc/apt/sources.list 和 /etc/apt/sources.list.d 中列出的源的索引，这样才能获取到最新的软件包。等更新完毕以后再敲命令：apt-get install vim命令即可。

DotNet Core部署到CentOS

Sat, 03 Feb 2018 10:00:00 +0800

本文基于初次或再次尝试部署.Net Core应用到Linux服务器上，我尝试后自我总结的经验一个简单的Demo,尝试部署在Linux服务器上和跨服务器访问数据库。

环境介绍

本地使用Visual Studio 2017开发，使用的.NetCore SDK版本为2.1.4；
数据库使用的MSSQLServer，部署在阿里云服务器上，WindowServer；
Demo部署在腾讯云服务器上，CentOS系统;
CentOS中安装了.net CoreSDK 2.1.4（开发和部署的环境最好一致，我在这里掉过坑）
代码管理通过Git来进行，在本地安装了Git，在CentOS中也安装了Git；
利用jexus进行反向代理；

项目介绍

建立一个Asp.Net Core项目，这个建立过程就不贴图了，步骤简单。此处还没有使用到Docker,建立项目时,没有勾选Docker支持。

整个项目从搭建到运行的简略过程

建立实体，只加了一个User类，里面就是基本的用户名、密码、地址和创建日期。

public class User
{
 public User()
 {
 this.CreateDate = DateTime.Now;
 }


 public int Id { get; set; }
 public string UserName { get; set; }
 public string Password { get; set; }
 public string Address { get; set; }
 public DateTime CreateDate { get; set; }
}

接下来是建立DbContext

public class HDShopDbContext:DbContext
{
 public HDShopDbContext(DbContextOptions<HDShopDbContext> options)
 :base(options)
 {


 }
 protected override void OnModelCreating(ModelBuilder modelBuilder)
 {
 //modelBuilder.Entity<User>().ToTable("xxxx");
 }


 public virtual DbSet<User> User { get; set; }
}

配置服务，在项目中已经默认的将EFCore相关的Nuget包加入进来了，在StartUp.cs文件中进行服务配置，使用

services.AddDbContext<HDShopDbContext>(d => d.UseSqlServer(Configuration.GetConnectionString("Default")));

Starup文件整体内容

Docker容器中开始_Net Core之路

Mon, 01 Jan 2018 10:00:00 +0800

开始写这篇博客前，已经尝试练习过好多次Docker环境安装,.Net Core环境安装了，在这里替腾讯云做一个推广,假如我们想学习、练手.net core 或是Docker却苦于没有开发环境，服务器也不想买，那么我们可以使用腾讯云提供的开发者实验，每个实验项目每天可以免费使用一次，时常45分钟，学习技术单靠看几篇文章、几本书是完全不够的，”实践方能出真知“。

腾讯云开发者实验连接地址

环境介绍

在练习平台上的环境是CentOS7.3版或许你会说我不懂Linux怎么办，没关系，我也是小白，学点基本命令暂时能用起来就行了。毕竟我们不是专门在Linux下搞开发的。(Linux下专业人士见谅哈)。

Docker容器,如果说Docker容器还不知道什么概念的话，我推荐先暂停，先学习下Docker的基本概念，弄清楚Docker是什么，总比越看越糊涂好.

dotnet镜像(也可以是aspnetcore镜像这两者的关系我将稍后解释).

OK，开始动手！

启动实验，安装Docker

我进入的搭建Docker环境，当然也可以从其他实验中开始着手。从搭建Docker环境中进入我们可以看到要求的步骤，方便我们快速安装，仅此而已。

1、先来安装Docker环境

yum install docker-io -y //CentOS已经将Docker软件包放在了Extras软件源中，直接利用即可
docker -v //查看docker的版本 version
systemctl start docker.service //开启Docker服务
systemctl enable docker.service //开机启动Docker服务

安装Docker环境时需要等待一到两分钟……..安装完毕，接下来我们需要将Docker服务进行启动

到这里Docker环境的安装就已经结束了。当然我们还需要配置Docker，开始配置DockerHub：

echo "OPTIONS='--registry-mirror=https://mirror.ccs.tencentyun.com'" >> /etc/sysconfig/docker
systemctl daemon-reload //重新载入 systemd，扫描新的或有变动的单元
systemctl restart docker.service //重启docker服务

安装.Net Core环境

接下来我们将有两种方式来安装我们的.net core环境

方式一：在Docker容器中获取dotnet镜像

docker pull microsoft/dotnet //安装.net core镜像

这种方式提供给了我们.net core的整套模板，编译工具，RunTime等等,一应俱全。我们可以通过docker命令查看我们已经拥有的镜像，注意这需要在Linux主机下查看，别跑到容器中去了

docker images // 查看当前已有的docker镜像文件

当前命令下我们可以看到dotnet镜像已经被我们拉取下来了。继续，我们开始新建并运行一个以dotnet镜像的容器

docker run -it microsoft/dotnet //启动一个dotnet镜像

看到root后面变化了没，这说明我们已经进入了一个容器，Docker当新建一个容器后，会给这个容器分配一个id，也就是我们所看见的那串字符串了。继续，通过命令新建一个web应用

自我总结和学习表单提交的几种方式 (二)

Fri, 08 Dec 2017 10:00:00 +0800

表单提交感觉项目中用到的次数越来越多了，但是遇到的问题也越来越多，使用的解决方式也层出不齐，利用周末时间，自己学习学习，然后继续总结下几种表单提交的方式。

【4】传统submit提交方式拦截，改造成ajax提交

<form id="form" enctype="multipart/form-data">
 <label for="name">姓名：</label>
 <input type="text" id="name" data-bind="value:vm.name" /><br />
 <label for="address">住址：</label>
 <input type="text" id="address" data-bind="value:vm.address" /><br />
 <label for="tel">手机号：</label>
 <input type="text" id="tel" data-bind="value:vm.tel" /><br />
 <input type="submit" value="添加" />
</form>

 $("#form").submit(function () {
 var model = ko.mapping.toJS(vm.entity);
 $.ajax({
 url: '@Url.Action("AddCustomInfo")',
 type: this.method,
 dataType: "Json",
 data: { fileInfo: model },
 success: function (data) {
 if (data.result) {
 layer.alert("添加成功！");
 $("#myModal").modal("hide");//隐藏弹框
 }
 }
 });
 return false;//阻止表单提交
 });

自我总结和学习表单提交的几种方式 (一)

Sat, 25 Nov 2017 10:00:00 +0800

最近总是记不住表单提交的几种方式，并且各种方式的适应场景也不知道，干脆来总结一次，当再学习过程。

首先从最简单的开始练手：

【1】纯form表单形式，无js和ajax ，提交路径有action决定，方式由method决定，如果需要传输文件加上enctype

我的表单内容:两个下拉选择、一个文件选择和一个输入框

 <form action="@Url.Action("AddFile", "Assistant")" id="form" method="post" class="form-horizontal" enctype="multipart/form-data" >
 <div class="form-group">
 @Html.LabelFor(m => m.FileDescription, new { @class = "col-md-2 control-label" })
 @Html.TextAreaFor(m => m.FileDescription, new { @class = "form-control col-md-10", rows = 5 })
 </div>
 <div class="form-group">
 @Html.LabelFor(m => m.FileType, new { @class = "col-md-2 control-label" })
 @Html.DropDownListFor(m => m.FileType, (IEnumerable<SelectListItem>)ViewBag.FileType, new { @class = "form-control col-md-10" })
 </div>
 <div class="form-group">
 @Html.LabelFor(m => m.File, new { @class = "col-md-2 control-label" })
 @Html.TextBoxFor(m => m.File, new { type = "file", id = "file", @class = "form-control col-md-10" })
 </div>
 <div class="form-group">
 @Html.LabelFor(m => m.IsPublic, new { @class = "col-md-2 control-label" })
 @Html.DropDownListFor(m => m.IsPublic, (IEnumerable<SelectListItem>)ViewBag.IsPublic, new { @class = "form-control col-md-10" })
 </div>
 <div class="form-group">
 <input type="submit" id="AddFile" class="btn col-md-offset-2" value="添加" />
 <button type="button" class="btn btn-default" data-dismiss="modal">关闭</button>
 </div>
 </form>

后台成功接收到了需要的信息

AspNet MVC下自定义错误页和展示错误页的几种方式

Sun, 19 Nov 2017 10:00:00 +0800

在网站运行中，错误是不可避免的,错误页的产生也是不可缺少的。这几天看了博友的很多文章，自己想总结下我从中学到的和实际中配置的。

先得需要知道产生错误页的来源，一种是我们的.NET平台抛出的，一种是网站所依赖的宿主抛出的，一般来讲我们所依赖的宿主就是IIS了。

IIS中的错误页入口：

其中的错误码想必并不陌生

这里是在服务器上找不到所需资源时抛出的错误页,在这里可以设置需要展示的错误页面，只需将预定的错误页面加入服务器中，然后在指定状态码下配置路径即可。

这是请求在IIS中时，还未完全进入到asp.net mvc中，这里需要理解什么是未完全进入，IIS7+的版本中,不依赖于请求路径末尾的标识信息，利用mvc中的urlRoutingModule进行处理，在我们配置mvc的路由时,首先的第一条：

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

便是隔离非mvc内部的使用文件，如果请求的只是服务器上的文件，那么路由便会在这里进行过滤，使之不匹配具体路由信息。也就只是和mvc打了个招呼然后就走了,没有进入mvc中搞事情。第二种是,进入了asp.net mvc的管辖范围，然后在其中出错了，便是跳到我们在程序中配置的错误页了。

讲讲我从博友那里学到的、看到的几种方式。

第一种是在web.config中通过customError配置。

<customErrors mode="On" defaultRedirect="~/Error/ErrorPage">
 <error statusCode="404" redirect="~/Error/ErrorPage404" />
</customErrors>

但是这种方式不怎么令人接受，太过于简单，没有一点异常信息，并且有时候还不能起效果，我不太喜欢这种方式。这种是用框架封装好的，利用的是将要说的第三种的强大方式实现的,当有异常发生又没得捕获时，最终利用的第三种方式自动实现。 第二种是利用HandlerErrorAttribute 特性，利用AOP的方式，当有异常出现时，便会进入具体实现了这个特性的，且被注册了的ExceptionAttribute职责中。

namespace SAssassin.Web.Core.Filter
{
 /// <summary>
 /// 异常处理之日志记载采用消息队列方式
 /// </summary>
 public class MyExceptionAttribute : HandleErrorAttribute
 {
 public static Queue<Exception> ExceptionQueue = new Queue<Exception>();
 public override void OnException(ExceptionContext filterContext)
 {
 ExceptionQueue.Enqueue(filterContext.Exception);
 filterContext.HttpContext.Response.Redirect("~/ErrorPage/CustomErrorPage");
 base.OnException(filterContext);
 }
 }
}

在这里，我可以得到异常信息，也可以解析具体的异常报错原因，比如404，500… 可以通过这种形势，将其转移到不同的自定义错误页面上，此处我增加了一个控制器CustomErrorPageController,专门用来存放错误页面，原有的Shared下的Error.cshtml错误页面也仍然存在着。我比较喜欢这种方式，一来可以看到异常信息，而来可以设计需要跳转的错误页面。

DotNet下发送邮件遇到问题及解决方案

Sun, 22 Oct 2017 10:00:00 +0800

.NET后台代码利用QQ邮箱服务器发送邮件遇到的问题：“mail from address must be same as authorization user”

首先，看下代码实现

public class EmailHelper
 {
 /// <summary>
 /// 发送邮件
 /// </summary>
 /// <param name="subject">主题</param>
 /// <param name="body">内容</param>
 public static void SendEmail(string subject,string body)
 {
 var mailFrom = ConfigurationManager.AppSettings["mailFrom"];
 var mailTo = ConfigurationManager.AppSettings["mailTo"];
 var mailCC = ConfigurationManager.AppSettings["mailCC"];
 var smtp = ConfigurationManager.AppSettings["smtp"];
 var smtpPort = Convert.ToInt32(ConfigurationManager.AppSettings["smtpPort"]);
 var emailAccount = ConfigurationManager.AppSettings["emailAccount"];
 var emailPassword = ConfigurationManager.AppSettings["emailPassword"];


 　　　　 //邮件内容信息
 MailMessage mailMessage = new MailMessage
 {
 From = new MailAddress(mailFrom),
 Subject = subject,
 Body = body,
 };
 mailMessage.To.Add(mailTo);
 mailMessage.CC.Add(mailCC);


 　　　　 //邮箱服务器配置
 SmtpClient smtpClient = new SmtpClient(smtp, smtpPort)
 {
 Credentials = new NetworkCredential(emailAccount, emailPassword),
 EnableSsl = true,
 };


 　　　　 //发送邮件
 smtpClient.Send(mailMessage);
 }
 }

配置文件：

AspNet MVC CodeFirst模式数据库迁移步骤

Sun, 15 Oct 2017 10:00:00 +0800

利用Code First模式构建好基本的类后，项目也开始搭建完毕并成功运行，而且已经将数据库表结构自动生成了，但是，我有新的类要加入,有字段需要修改，就得将这部分修改同步到数据库中，利用数据库迁移，将原有结构不改动，将新建类进行单独建表操作，或者是已有数据库表，改变字段，那就修改表。

迁移步骤:

1、打开程序包管理器控制台：工具->NuGet包管理器->程序包管理器控制台.(当然还有其它方式也可以打开，我比较喜欢这种)

点击后将弹出程序包管理器控制台

极其要注意的是默认项目！！！

2、启动数据库迁移，执行命令：enable-migrations

由于Models不一定就是直接利用项目中已有的文件夹Models,从而当你选中启动项目为asp.net mvc 框架类型时，此处将会报错

具体来看我当前项目的分布情况：

我将模型分离出来了，以至于当我默认选中SearchEngine为启动项目时，在程序包管理器控制台中输入的第一个命令就会报错

解决方案：选中默认项目，选择为DbContext所在的项目，此处我的是类库

成功操作会如下提示：

并且在DbContext同级目录下增加了migrations目录

3、开始数据库迁移命令

1.Add-migration [自定义版本名称]

输入add-migration updateorderheader

2.update-database

此处如果和我一样将DbContext单独分割出来的需要注意，需要在当前类库的配置文件中加上数据库的连接地址

如果是直接在asp.net mvc框架中的Models中加入的DbContext，则可不必，会直接读取Web.Config文件中的连接字符串。

等待命令执行中时出现异常了。

开始寻找我电脑中的SQL Server Configuration Manage ，如果有则打开，找到

配置TCP/IP协议为已启用即可。我的本地没有该工具，只能通过如下方式找到该处，点击我的电脑右键->管理->服务和应用程序->SQLServer配置管理器 ( 两次找这工具都没找到，貌似都是直接从这解决的），重新输入命令，等待执行

初步成功，由于数据库中有些表无需更改，我们可以在migrations目录中，更改需要增加或修改的具体表

通过修改其中的CreateTable/DropTable，可以控制哪些表需要改动

namespace SAssassin.EF.Model.Migrations
{
 using System;
 using System.Data.Entity.Migrations;


 public partial class updateorderheader : DbMigration
 {
 public override void Up()
 {
 CreateTable(
 "dbo.MyFileInfoes",
 c => new
 {
 Id = c.Int(nullable: false, identity: true),
 FileName = c.String(),
 FileDescription = c.String(),
 FilePath = c.String(),
 FileType = c.Byte(nullable: false),
 FileSize = c.String(),
 FileStatus = c.Byte(nullable: false),
 IsPublic = c.Byte(nullable: false),
 UserId = c.String(),
 UserName = c.String(),
 CreateDate = c.DateTime(nullable: false),
 LastModityDate = c.DateTime(nullable: false),
 })
 .PrimaryKey(t => t.Id);
 }


 public override void Down()
 {
 DropTable("dbo.MyFileInfoes");
 }
 }
}

4、修改代码配置，实现之后的操作没那么麻烦

WebSocket部署服务器外网无法连接解决方案

Sun, 24 Sep 2017 10:00:00 +0800

首先要说的是我遇见的问题：

WebSocket connection to 'ws://www.xxxx.com/xxx/xx' failed: Error during WebSocket handshake: Unexpected response code: 200

网站绑定到了服务器，直接在服务器上访问webSocket服务是可行的，但是当我用外网访问时，这个错误就是我最大的敌人，在这之前还遇到过几个小毛贼，可以轻松解决，不再提，直面boss吧

花费两个下午的时间寻找解决方案，但是并没有找到，各种解决方案，但是直接来描述.NET下使用这一问题的，却是不多，然而面对了这一问题的朋友，大把的有。

这个无关浏览器问题，我有火狐，谷歌，IE测试过，该出的问题还是会有。

开发平台：.NET,利用ASP.NET MVC搭建网站，在其中利用WebSocket服务，目的是在网站内设计一个讨论平台。

具体来说一说：

首先，看下我的网页代码：

<script type="text/javascript">
 $(function () {
 var url = "ws://xxxx:xx"+"@Url.Action("RequestProcessCenter")";
 var ws;
 function connect() {
 ws = new WebSocket(url);
 $("#TopicContent").append("正在连接\n");
 ws.onopen = function () {
 $("#TopicContent").append("已经连接\n");
 };
 ws.onmessage = function (evt) {
 console.log(evt.data);
 $("#TopicContent").append(evt.data);
 };
 ws.onclose = function () {
 $("#TopicContent").append("已经关闭\n");
 };
 ws.onerror = function (evt) {
 console.log(evt.data);
 $("#TopicContent").append(evt.data);
 };
 };
 $("#send").click(function () {
 console.log(1);
 console.log(ws.readyState);
 console.log(WebSocket.OPEN);
 if (ws.readyState == WebSocket.OPEN) {
 ws.send($("#content").val());
 $(this).val("");
 }
 else {
 $("#TextMessge").append("连接已经关闭");
 }
 });
 $("#open").click(function () {
 connect();
 });
 $("#close").click(function () {
 ws.close();
 });
 });
 </script>

后台代码：

利用微软认知服务实现语音识别功能

Sun, 20 Aug 2017 10:00:00 +0800

想实现语音识别已经很久了，也尝试了许多次，终究还是失败了，原因很多，识别效果不理想，个人在技术上没有成功实现，种种原因，以至于花费了好多时间在上面。语音识别，我尝试过的有科大讯飞、百度语音，微软系。最终还是喜欢微软系的简洁高效。(勿喷，纯个人感觉)

最开始自己的想法是我说一句话(暂且在控制台上做Demo)，控制台程序能识别我说的是什么，然后显示出来，并且根据我说的信息，执行相应的行为.(想法很美好，现实很糟心）初入语音识别，各种错误各种来，徘徊不定的选择哪家公司的api，百度上查找各种语音识别的demo，学习参考，可是真正在.NET平台上运行成功的却是寥寥无几，或许是我查找方向有问题，经历了许多的坑，没一次成功过，心灰且意冷，打了几次退堂鼓，却终究忍受不住想玩语音识别。

可以看看我VS中的语音demo

第一个是今天的主角-稍后再提。

第二个和第三个是微软系的系统自带的System.Speech.dll和看了微软博客里面的一篇文章而去尝试的Microsoft.Speech.dll 可惜文章写的挺好的，我尝试却是失败的，并且发现一个问题，就是英文版的微软语音识别是无效的(Microsoft.Speech.Recognition)，而中文版的语音合成是无效的(Microsoft.Speech.Synthesis).，因此，我不得不将两个dll混合使用，来达到我想要的效果，最终效果确实达到了，不过却是极其简单的，一旦识别词汇多起来，这识别率直接下降，我一直认为是采样频率的问题，可是怎么也找不到采样频率的属性或是字段，如有会的朋友可给我点信息，让我也飞起来，哈哈。

第四个是百度语音识别demo，代码简洁许多，实现难度不难，可是小细节很多，需要注意，然后是雷区挺多的，但是呢，指导走出雷区的说明书却是太少了，我是踩了雷，很郁闷。

首先来看看，现在市面上主流语音识别设计方式：

1、离线语音识别

离线语音识别很好理解，就是语音识别库在本地或是局域网内，无需发起远程连接。这个也是我当初的想法，自己弄一套语音识别库，然后根据里面的内容设计想要的行为请求。利用微软系的System.Speech.dll中的语音识别和语音合成功能。实现了简单的中文语音识别功能，但是一旦我将语音识别库逐渐加大，识别率就越来越低，不知是我电脑麦克风不行还是其它原因。最终受打击，放弃。当我试着学习百度语音时，也发现了离线语音识别库，但是呢官方并没有给出具体的操作流程和设计思路，我也没有去深入了解，有时间我要好好了解一番。

 1 using System;
 2 //using Microsoft.Speech.Synthesis;//中文版tts不能发声
 3 using Microsoft.Speech.Recognition;
 4 using System.Speech.Synthesis;
 5 //using System.Speech.Recognition;
 6
 7 namespace SAssassin.SpeechDemo
 8 {
 9 /// <summary>
10 /// 微软语音识别 中文版 貌似效果还好点
11 /// </summary>
12 class Program
13 {
14 static SpeechSynthesizer sy = new SpeechSynthesizer();
15 static void Main(string[] args)
16 {
17 //创建中文识别器
18 using (SpeechRecognitionEngine recognizer = new SpeechRecognitionEngine(new System.Globalization.CultureInfo("zh-CN")))
19 {
20 foreach (var config in SpeechRecognitionEngine.InstalledRecognizers())
21 {
22 Console.WriteLine(config.Id);
23 }
24 //初始化命令词
25 Choices commonds = new Choices();
26 string[] commond1 = new string[] { "一", "二", "三", "四", "五", "六", "七", "八", "九" };
27 string[] commond2 = new string[] { "很高兴见到你", "识别率", "assassin", "长沙", "湖南", "实习" };
28 string[] commond3 = new string[] { "开灯", "关灯", "播放音乐", "关闭音乐", "浇水", "停止浇水", "打开背景灯", "关闭背景灯" };
29 //添加命令词
30 commonds.Add(commond1);
31 commonds.Add(commond2);
32 commonds.Add(commond3);
33 //初始化命令词管理
34 GrammarBuilder gBuilder = new GrammarBuilder();
35 //将命令词添加到管理中
36 gBuilder.Append(commonds);
37 //实例化命令词管理
38 Grammar grammar = new Grammar(gBuilder);
39
40 //创建并加载听写语法(添加命令词汇识别的比较精准)
41 recognizer.LoadGrammarAsync(grammar);
42 //为语音识别事件添加处理程序。
43 recognizer.SpeechRecognized += new EventHandler<SpeechRecognizedEventArgs>(Recognizer_SpeechRRecongized);
44 //将输入配置到语音识别器。
45 recognizer.SetInputToDefaultAudioDevice();
46 //启动异步，连续语音识别。
47 recognizer.RecognizeAsync(RecognizeMode.Multiple);
48 //保持控制台窗口打开。
49 Console.WriteLine("你好");
50 sy.Speak("你好");
51 Console.ReadLine();
52 }
53 }
54
55 //speechrecognized事件处理
56 static void Recognizer_SpeechRRecongized(object sender, SpeechRecognizedEventArgs e)
57 {
58 Console.WriteLine("识别结果：" + e.Result.Text + " " + e.Result.Confidence + " " + DateTime.Now);
59 sy.Speak(e.Result.Text);
60 }
61 }
62 }

2、在线语音识别。

AspNet MVC路由生成URL过程

Sat, 25 Mar 2017 10:00:00 +0800

这次谈一谈Asp.Net MVC中所学到的路由生成URL的相关技术，顺便提一提遇到的一些坑，真的是掉坑掉多了，也就习以为常了，大不了从坑里再爬出来。初学者，包括我，都以为，mvc的核心是模型视图控制器，其余都是辅助，但是路由却也是可以独立成一个角色的。从ASP.NET发展来，路由已从一个小小角色演变成了独立的一方了，所以这个认识必须打破原有建立的思想。

首先得知道一个概念，路由的功能是什么？简单的讲就是你拿给我一个地址，我通过路由来查询一下，然后转交给你结果，路由好比一个服务区，确实如此，MVC中，当用户提交一个请求URL，MVC中的URL和其它Web中的是有点区别的，此处的统一资源定位符更多的是侧重于某个控制器类上的某个操作，和磁盘上的资源打的交道是比较少的。服务器上接收到请求URL后，交由路由系统进行处理，通过查询已经注册的路由信息，查看是否有该URL请求，如果有，则进行相应的逻辑操作处理，最终返回需要的HTML和URL，如果找不到URL，那么进入默认页面，或者是直接报错。

具体的细节在谈一谈：路由的核心是一些非常简单的算法，基于一个由RouteCollection类和RouteBase类组成的简单抽象对象。通过使用RouteCollection.GetVirtualPath()方法来处理相关逻辑并最终生成URL，

public VirtualPathData GetVirtualPath(RequestContext requestContext,RouteValueDictionary values);
public VirtualPathData GetVirtualPath(RequestContext requestContext,string name,RouteValueDictionary values);

路由集合通过这些方法遍历每一个路由并通过已有参数匹配是否能生成URL，如果有路由应答了，那么它就返回一个包含了URL的VirtualPathData实例以及其它信息，没有就返回一个空值，并查询下一个路由如果有利用第二个重载方法的，那么更加简单了，不需要一个一个匹配，直接通过name参数，该参数是路由名称的字符串，可以直接匹配路由集合中该路由名称，一句话说就是直接定位，找到了并符合就生成URL，返回空值就不再匹配其它路由了。

URL生成详解：

1.通过RouteCollection.GetVirtualPath()方法,将RequestContext对象，一个包含值的字典，以及用来选择生成URL的路由名称传入方法中。

2.路由机制查看要求的路由参数，这个参数是必须要存在的参数，并确保提供的路由值字典为每一个必须存在的参数提供了一个值，否则直接返回空值。

3.一些路由可能包含没有对应路由参数的默认值，如果用户传入的路由值字典中提供了这个参数，并且提供了值，那么这个字典中的值必须和默认参数中给定的值相匹配，不然就返回空值。

4.然后路由系统应用路由的约束，检查是否符合。

5.匹配成功，尝试利用字典中的值填充对应参数，进而生成URL。

到这里URL就生成完成了，这个过程中要求比较多，但是跟着步骤来，应该还是容易理解的。还要提及的是一个溢出参数：这是指在URL生成过程中使用但没有在路由定义中指定的路由值，具体指的是路由的URL 默认字典，约束字典中的值，外界值不能做为溢出参数使用。溢出参数会做为查询字符串参数附加在生成的URL之后，只要路由指定的参数达到满足，是否指定额外参数则无关紧要

针对于多线程概念的理解

Tue, 28 Feb 2017 10:00:00 +0800

今天是2月28日，本来的想法是每月一两篇，但是时间有点太匆忙，在这里也想向大家说一说，时间很少，愿各位好好珍惜，今天谈一谈多线程，如同其文字描述一样，线程很多，这也是多线程存在的原因，那首先什么是多线程呢，在这里，表明一下我的理解方式和我对多线程学习采用的一种套路。

首先，我是一个想象流，很多事情是可以通过想象空间进行理解的，文字性的东西总归有它的约束存在，不可能有什么是可以一句话概括其所有，其实.NET 甚至是很多的编程语言，内部都是由生活的抽象得到的，有时候，很多没有理解的技术点，或是没有遇到的，没有经历过的解决一件事情的办法，在程序中也可以得到认识，犹如读了很多感悟生活，感悟人生的书，只不过我们的许多见解是在程序中得到的。

现在，谈一谈，多线程的想象空间，最初学习时，看到多线程的概念，和各种实现多线程的方法，我是拒绝的，感觉太难了，完全没有逻辑性可言，但是当我用想象空间进行学习时，压力几乎消失了，比如说一个进程中开了四个线程，其中一个主线程，三个子线程，可以好比如说四座相互平行的桥，桥下是水，其中主线程是作为主桥，来往的车辆最多，而其它三个副桥暂时封闭，当需要运行多个任务并且希望时间又不浪费，那么三个副桥就开通了，四桥同时通车，多线程的概念也就结束了，什么？这么简单，对就是这么简单，毕竟那是我们生活的抽象。

而多线程还是没给一个定义呢，之前已经说了，文字性的东西不足以描述一个事情，我们只需要知道它的想象即可，桥与桥之间是相互独立的，桥上的资源是相互独立的，并且都是一样的，也就是在磁盘中，克隆出相同的资源，但是代码是只有一份的，运行的时候我们可以重复使用。

说说.NET中多线程的实现方式：

首先需要知道，多线程总共有的几种名词：Thread ThreadPool Task Parallel await/async 就这么几种，并且由于前两种的使用是几年前的定义其中用的委托还不是.NET4.0定义的Action和Func这种委托，因此使用的一般是以前的应用程序，但是不是说他们已经淘汰了，只不过后面有更方面的使用形式，前期的只是失去了光辉，其中await/async理解上比较复杂，实际掌握的人还是不多，使用比较多的还是Task和Parallel,我比较喜欢使用Parallel，简单粗暴，并且主线程也在执行中，没有太大的浪费，顺便提一句，Task Parallel 都是基于线程池才有的。线程想要通过程序调试去理解，是很难的，记得听到一个朋友说，她想调试下线程，然后理解它，但是每一次都是不一样的结果，其实这也反应了一个问题，线程的不可预测性，并且当线程数量很多时，线程的启动和结束都是无序的，线程的执行能力也是不一样的，想要通过调试理解，由此也是很困难的

再次提到想象空间，通过它，理解多线程来说不是什么难事，如前面的例子，四座副桥上尽管都是在跑着汽车，但是呢谁能保证哪座桥汽车最先没有呢，结果的不可预测性，在现实生活中也是的，假设你只能看到四座桥的风景，车来车往是否结束都不知道，能否保证那座桥上的汽车已经跑完了呢，答案也是无法确定。

以上所说了这么多文字，也套用了我说的里面那句话，文字不足矣描述需要的信息，但是我想表达的想象空间，希望能帮助碰上瓶颈的朋友们过了多线程这道坎，并且由于每个人对多线程想象空间的建模不一样，这是我碰到过的，有人理解多线程为管道，有人理解为马路，都是不错的。并且，也许在一部分人中，不需要这样的想象空间，那也可以帮助下需要的人讲解下。

好了到此结束了，时间很紧迫，估计下一次也不知道什么时候才有时间写下一篇自己的见解。珍惜时间吧，Everyone！

谈谈个人代码对团队合作影响

Sun, 01 Jan 2017 10:00:00 +0800

这几天正接手一个项目，属于后期功能拓展，要拓展这个项目，一定程度上要看到源码的部分，然后烦心的事情就来了，这代码写的真是让人挺无语的，原先写完整个项目的是已有多年工作经验的开发者，但是整个代码下来，逻辑性不强，单看完整个流程，各个模块的作用，就花了一两天的时间，这还没涉及到代码部分，缺乏相应的注释。这也给了我很深的印象和感悟，不管是个人写代码，还是团队合作，对于框架要明确，有结构图，有相应的注释，命名规范相当重要，尽管项目不大，也要逻辑分明，这是对于日后拓展和维护都是有好处的，所谓在实战中学习，真的是学到了好多，写自己的代码改动日志，将任务，思路，想法，原先基础上改动地方全部记录下来，这对于自己来说真的是很有用的事情，或许写着日志的时候，项目中不足的地方也会一并解决。

具体谈谈这次项目中看到的哪些不足之处：

首先，在整个框架设计上，就完全是依据要有功能就实现功能的思路来，结果如何呢，造成了很多代码上的冗余，比如说，在访问数据库上，由于这是一个WPF的窗体应用程序，在窗体后台，直接用上了访问数据库的语句，不是单单的SQL语句，而是实在的数据库访问，连接数据库，CRUD操作，一并封装到了所要的功能中，这里造成了代码的太多冗余，从框架的角度考虑，本应该是SQLHelper的活，却被一个人承包了，UI,BLL,DAL,SQLHelper全部集中在一个里面，真的是不敢想象。代码看完，就在那想，以后的自己真的是不要这样，毕竟现在就有了仇恨，哈哈。

其次，代码部分的注释是相当少，没有明确的解释，就连命名上也是大打折扣，使用中文拼英的缩写作为部分命名，看着这些东西，唉，心累，代码部分也只是看了我要拓展部分的相关代码，既然出自同一人之手，并且我看的还是整个项目的主干线，想也知道，其它部分的风格应该如出一辙，不管如何，这一次的拓展工程，真的是学到了太多太多，团队合作时，需提前进行规范，框架规范，命名规范，这些真的是很重要，想要一个可以日后维护，拓展轻松的项目，那么开始制定计划的时候就要提前规划好需要的东西，宁可费点时间，也是值得的。

最后，最想吐槽的一部分就是在于我的拓展需要用到已经搭建好的数据库，但是当我编写访问数据库的方法时，竟然发现，连数据库名字都是中文的，这就尴尬了，一个下午找着解决方案，我天呐，最后的办法居然还是利用原先项目中已经存在的连接数据库语句搞定的，代码也没深究了。

对于ASPNET MVC中页面强类型的个人理解

Sun, 13 Nov 2016 10:00:00 +0800

进入ASP.NET MVC学习发现很多和winform不同的东西，但是利用的C#语言还是没有变化，更多的是利用了新的语言，html jquery ajax…..唉心累，一本书一本书看的去看完了回想起来的时候是很快乐的，在此说一说学习之中遇到的比较深的坎:

在对于页面强类型学习的时候，刚开始感觉还是很轻松的，不就是直接在Controller中用一次viewdata["***"]=value并且在View中通过@model **** 就可以了嘛，又或是直接利用ViewData.Model做更简单的事，还有viewbag,tempdata等就不说了，

但是呢，自从遇到一次坎后才知道，并不是那么简单，比如说viewdata使用的基本原理是利用键值对形式，但是呢这个object对应的保存的数据到底是什么类型的呢，是用object抽象形式保存还是用原生的形式呢，比如说我有一个ProductCategory的类，并且进行var pro = new ProductCategory(***)创建一些信息，在通过ViewData[“objPC”]=pro;那么这个pro保存在objPC保存的形式类型是哪种呢？object or ProductCategory？

如果是说保存为object那么在view里写入@model ProductCategory 也就说的通顺了，再次进行强制转换嘛。实际上呢，不引用这那句话，在view里直接写Model并且通过点的形式调用其成员，也是行得通的，只不过Model去调用的话必须要保证那个属性或是方法一定存在那个值的类型之中，也就证明了一点，value的值传给viewdata保存时并不是用object形式进行保存的，而是用它的原生形式，

@model ProductCategory的引入只是为了在View中强制这个传入的值的类型，并且为了在编写代码的时候出现的错误少点，而@using ***更是和C#中的使用是一样的，毕竟@下就是c#代码了。

最后在说下在linq查询的条件下，通过controller传递过来的并不是确定的类型，什么意思呢，传过来的其实还是查询语句，并且此时查看Model的值时，也是显示一个查询语句，这归因于是使用延时加载的原因，当真正需要的时候再去查询，并且查询出来的类型大多数是利用的IQueryable<>类型,因此在View中提前指定好强类型页面也是可以的，毕竟知道了这个传过来的集合的类型是已经确定的，怎么不利用它里面的属性做更多的事情呢。

ASP.NET MVC第一次讲解在这里先告一段落，毕竟我也是刚刚学习不长时间的入门者，但是这种MVC的思想值得我们在生活中去借鉴,Separation of Concerns.

对于序列化的相关学习与理解

Thu, 13 Oct 2016 10:00:00 +0800

刚开始接触.NET的序列化时，完全不知道是什么东西，一脸茫然，在学习中，看到有人直接加一个[Serialization],然后说这是序列化的表示，顿时震惊了，这是什么？后来在图灵丛书的精通C#书中学习到了这是C#的一种特性，其目的是将对象持久化为二进制格式。比如以接下来这个案例作为学习：

// 系统配置实体类
[Serializable]
public class SysConfig
{
 public int COMno { get; set; }
 public double VolValue { get; set; }
 public double CurrentValue { get; set; }
 public int EquipmentId { get; set; }
}

此处在整个类的前面加上了[Serialization]代表着将整个类可以进行序列化成二进制格式如果不想对其中的某一属性或方法序列化，可以在该属性或方法前加上[nonSerialized]标识，这样一来只有该被指定的不会被序列化了，我们设置了四个属性，分别代表了端口号，电流值，电压值，及设备号。这是在工控开发中较为常见的配置。在窗口相关代码下看其操作方式：

目的是很明确的，将信息持久化的保存在文件中，对于两种形式的保存方式也将体现出序列化的与众不同。

public partial class FrmConfig : Form
{
 SysConfig objSysConfig = null;

 public FrmConfig()
 {
 InitializeComponent();
 }


 // 文本方式保存信息
 private void btnTextToSave_Click(object sender, EventArgs e)
 {
 objSysConfig = new SysConfig()
 {
 COMno = Convert.ToInt32(this.txtCOMno.Text.Trim()),
 CurrentValue = Convert.ToDouble(this.txtCurrent.Text.Trim()),
 EquipmentId = Convert.ToInt32(this.txtEquipmentId.Text.Trim()),
 VolValue = Convert.ToDouble(this.txtVol.Text.Trim())
 };


 //【1】创建文件流对象
 FileStream fs = new FileStream("SysConfigText.obj", FileMode.Create);


 //【2】创建读写器(写)
 StreamWriter sw = new StreamWriter(fs);


 //【3】写入文件
 sw.WriteLine(objSysConfig.COMno);
 sw.WriteLine(objSysConfig.CurrentValue);
 sw.WriteLine(objSysConfig.EquipmentId);
 sw.WriteLine(objSysConfig.VolValue);


 //【4】关闭读写器
 sw.Close();


 //【5】关闭文件流对象
 fs.Close();
 }


 // 文本方式读取信息
 private void btnTextToRead_Click(object sender, EventArgs e)
 {
 //【1】创建文件流对象
 FileStream fs = new FileStream("SysConfigText.obj", FileMode.Open);


 //【2】创建读写器(读)
 StreamReader sr = new StreamReader(fs);


 //【3】读取文件
 objSysConfig = new SysConfig()
 {
 COMno =Convert.ToInt32(sr.ReadLine()),
 CurrentValue =Convert.ToDouble(sr.ReadLine()),
 EquipmentId =Convert.ToInt32(sr.ReadLine()),
 VolValue =Convert.ToDouble(sr.ReadLine())
 };


 //【4】关闭读写器
 sr.Close();


 //【5】关闭文件流对象
 fs.Close();


 this.txtCOMno.Text = objSysConfig.COMno.ToString();
 this.txtVol.Text = objSysConfig.VolValue.ToString();
 this.txtEquipmentId.Text = objSysConfig.EquipmentId.ToString();
 this.txtCurrent.Text = objSysConfig.CurrentValue.ToString();
 }


 // 序列化方式保存信息
 private void btnSeriaToSave_Click(object sender, EventArgs e)
 {
 objSysConfig = new SysConfig()
 {
 COMno = Convert.ToInt32(this.txtCOMno.Text.Trim()),
 CurrentValue = Convert.ToDouble(this.txtCurrent.Text.Trim()),
 EquipmentId = Convert.ToInt32(this.txtEquipmentId.Text.Trim()),
 VolValue = Convert.ToDouble(this.txtVol.Text.Trim())
 };


 //【1】创建文件流对象
 FileStream fs = new FileStream("SysConfigSeria.obj", FileMode.Create);

 //【2】创建二进制格式化器
 BinaryFormatter bf = new BinaryFormatter();

 //【3】调用序列化方法，信息序列化
 bf.Serialize(fs, objSysConfig);


 //【4】关闭文件流
 fs.Close();
 }


 // 序列化方式读取信息
 private void btnDeseriaToRead_Click(object sender, EventArgs e)
 {
 //【1】创建文件流对象
 FileStream fs = new FileStream("SysConfigSeria.obj", FileMode.Open);


 //【2】创建二进制格式化器
 BinaryFormatter bf = new BinaryFormatter();


 //【3】调用反序列化方法，信息反序列化
 objSysConfig = (SysConfig)bf.Deserialize(fs);


 //【4】关闭文件流
 fs.Close();


 this.txtCOMno.Text = objSysConfig.COMno.ToString();
 this.txtVol.Text = objSysConfig.VolValue.ToString();
 this.txtEquipmentId.Text = objSysConfig.EquipmentId.ToString();
 this.txtCurrent.Text = objSysConfig.CurrentValue.ToString();
 }
}
}

对于序列化方式中，binaryFormatter这个类是最关键的，其中的Serialize()和Deserialize()方法是序列化学习的关键所在，Serialize()方法通过给它一个文件流参数，相当于给定了笔和纸，再来一个参数是要序列化的对象，相当于要书写的信息，而反序列化就是将写好的作品在通过笔和纸在写回来而这次是看着那些写好的信息在写一份信息出来并且用一个容器保存这些信息，总而言之，言而总之，序列化可以想象成将一个对象转换成二进制形式保存，然后在将这些二进制对象封装，又可以变回一个对象的过程。这比文本文件的好处在于，在文件中序列化是以二进制方式保存，十分难看懂，而文本文件是以明文形式保存，并且在处理过程上，文本文件方式更见繁琐，但是不是说文本文件毫无用处，比如说写日志文件，你用序列化它那对自己直接面对日志文件而言，毫无疑问是一种相当愚蠢的方式，说的虽然严重了，但是主要是想表达我们不是说为了序列化而序列化文件，一种刻意为之的方式去使用。而是说当我们需要使用的时候，就用，不要强求，一般在项目开发中，针对于实体类而言，我们通常是先加上[Serialization]的，以便更好的应对项目的需求。

反射在AdoNet方面的应用

Sat, 01 Oct 2016 10:00:00 +0800

本来说通过传统的方式可以很方便的访问数据库不需要用到反射技术，但是为了将反射在ADO.NET中的作用体现出来，特意来试一下改良版的访问方式。

反射的学习需要一定的时间去理解，我学了有一阵子了，但也不敢保证是将反射学懂了，学无止境，反射的本身也体现了微软的才华。

反射的命名空间是System.Reflectional;项目用到反射之前需要引入，这不像它本身的功能，哈哈，可以动态的加载程序集，而不需要引入的方式，反射尤其名字联想到物理学中的镜面反射，也可以懂其大概意思，就是说通过给你一个程序集的完整路径名，你可以反射出一整套该程序集的信息，这个完整路径名，在很多时候都是通过写在配置文件中的，通过这样也得以将程序实现可配置，通过改变不同的程序集名字，又能实现可扩展性。

废话不多说，现在来看看反射是怎么改良ADO.NET的。

这是一种简单的方式访问数据库：

public SysAdmins AdminLogin(SysAdmins objAdmin)
{
    //【1】定义SQL语句
    string sql = "select AdminName,StatusId,RoleId from SysAdmins where AdminId=@AdminId and LoginPwd=@LoginPwd";
    //【2】封装参数
    SqlParameter[] param = new SqlParameter[]
    {
        new SqlParameter("@AdminId",objAdmin.AdminId),
        new SqlParameter("@LoginPwd",objAdmin.LoginPwd)
    };
    //【3】执行查询
    SqlDataReader objReader = SQLHelper.GetReader(sql, param);
    //【4】处理结果
    if (objReader.Read())
    {
        objAdmin.AdminName = objReader["AdminName"].ToString();
        objAdmin.StatusId = Convert.ToInt32(objReader["StatusId"]);
        objAdmin.RoleId = Convert.ToInt32(objReader["RoleId"]);
    }
    else
    {
        objAdmin = null;
    }
    objReader.Close();
    //【5】返回查询结果
    return objAdmin;
}

通过将表示层的信息进行封装，经过业务逻辑层，再到数据访问层，将信息解包，提取有用信息，并整合到SQL语句中，通过ADO.NET技术访问数据库，数据库内进行一系列项目需要的操作，得到想要的返回结果，并且又封装到原来的包中，整个过程的该部分已经结束，自动忽略一部分细节，毕竟我们主要讲的是该部分。而后我们通过反射来实现一下：

委托在窗体通信方面的见解

Tue, 06 Sep 2016 10:00:00 +0800

首次博客内容是将自己对于委托在窗体通信方面的应用做一次总结，也算是将自己的见解用言语来表达出来吧。在开始接触委托时云里雾里，完全没有这个概念的存在，更不用提委托用于窗体通信之中这么高深的运用了尽管在现在看来我还是觉得委托用在窗体通信中是一件很神奇的事情，不是说没有弄懂，而是说这里面的逻辑思维也值得我们去学习(思维是个关键的东西，一旦理解了，也会顺水推舟)。

首先委托的格式想必是一目了然

public delegate void MessageDele(string Message);

委托的五大步骤：

声明委托
根据委托创建具体方法
创建委托变量
委托变量关联具体方法
调用委托

然而在此处如果我们将窗体通信想象成主窗体和从窗体通信的话，那么必然存在一个问题，委托变量的放置问题。（本次只考虑主从窗体通信这种特殊情形，其余情形照搬该逻辑思路即可了）。例如，如果是主窗体向从窗体发送信息，是在主窗体里面定义委托变量并且绑定相关从窗体的方法，还是从窗体内定义委托变量，并且将委托变量与自身的相关方法进行绑定（该方法好比说是将主窗体传过来的信息展现出来），然后在主窗体中创建从窗体对象后，调用从窗体对象的委托变量用来发送信息呢。又或是在从窗体向主窗体发送信息情况下，委托变量是跟随谁的问题，一种是将委托变量定义在从窗体中，在主窗体中创建从窗体对象，然后通过从窗体对象去调用内部成员委托变量，并且绑定主窗体中的相关方法，另一种情况是主窗体中定义委托变量，并且绑定相关方法，再主窗体中创建从窗体对象，通过从窗体去调用主窗体中的委托（然而基本上这种方式完全不太推荐使用，不是说不可以用而是实现的步骤太过于复杂，付出的成本大于了其收益)。

主窗体向从窗体发送信息

主窗体中定义委托变量：

public partial class FrmMain : Form
{
 //【3】创建委托变量
 public MessageDele objMessageDele;


 public FrmMain()
 {
 InitializeComponent();


 FrmOther objFrmOther = new FrmOther();


 objFrmOther.Show();


 //【4】委托变量绑定方法
 objMessageDele += objFrmOther.Message;
 }


 //【5】调用委托变量
 private void btnclick_Click(object sender, EventArgs e)
 {
 objMessageDele(txt1.Text.ToString());
 }
}


//【1】声明委托（定义一个函数原型：返回值+参数类型+个数）
public delegate void ShowCount(string message);

从窗体提供委托实现方法：

文章 on ViatorLife Blog

Blazor WebApp Server&Cookie中AuthorizeAttribute的两重用途

框架说明

AuthorizeAttribute

Http请求

启用全局授权检查

不启用全局授权检查

Blazor WebApp Server&Cookie登出跨Tab下SignalR连接残留

框架说明

问题陈述

解决方案

新建项目

设置鉴权授权

设置服务端模拟数据

Blazor WebApp-Server&AuthenticationSchemes报错

背景描述

项目设置

Blazor WebApp-Server&Cookie鉴权授权

新建项目

设置鉴权授权

创建登录页面

Blazor WebAssembly&MudBlazor模板集成

新建项目

集成MudBlazor包

删除原有所有css文件

修改index.html

Blazor WebAssembly&JWT鉴权授权

新建项目

服务端令牌接口

服务端鉴权配置

Blazor WebAssembly&EdgeOne Pages部署记录

前言

EdgeOne Pages

新建项目

构建与部署

流水线构建

Blazor WebAssembly&Github Page部署记录

前言

新建Github仓库

新建项目

手动发布部署

本地发布

本地部署

修复问题

自动发布部署

Blazor WebAssembly&Azure Static App部署记录

前言

新建项目

Azure部署

ABP Framework-Blazor快速实践

前言

下载AbpCli

创建项目

创建库表

Asp.Net Core Blazor&SignalR 后端消息推送

前言

Blazor Server(WebApp)模式

Asp.Net Core Blazor&Blazorise快速实践

前言

Blazorise

搭建Blazor项目

接入Blazorise

增加CSS框架

配置css和js文件

Asp.Net Core Blazor快速实践

优势所在

托管模式

新建项目

DotNet&Coverlet统计单元测试覆盖率

前言

Coverlet

相关包

更换默认包

ReportGenerator

示例

新建项目

新建被测类和测试代码类

执行测试

ABP Framework-EventBus源码解析

Version