分類: 網路資訊

一 前置準備

1.1 前置條件

相應的充足資源的Linux服務器；

設置相應的主機名，參考命令：

 1 hostnamectl set-hostname k8smaster

Mac及UUID唯一；

若未關閉防火牆則建議放通相應端口，如下：

Master節點——

規則	方向	端口範圍	作用	使用者
TCP	Inbound	6443*	Kubernetes API server	All
TCP	Inbound	2379-2380	etcd server client API	kube-apiserver, etcd
TCP	Inbound	10250	Kubelet API	Self, Control plane
TCP	Inbound	10251	kube-scheduler	Self
TCP	Inbound	10252	kube-controller-manager	Self

Worker 節點——

規則	方向	端口範圍	作用	使用者
TCP	Inbound	10250	Kubelet API	Self, Control plane
TCP	Inbound	30000-32767	NodePort Services**	All

其他更多前置準備見：

二 主要組件

2.1 核心組件

• etcd：保存了整個集群的狀態；
• apiserver：提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API註冊和發現等機制；
• controller manager：負責維護集群的狀態，比如故障檢測、自動擴展、滾動更新等；
• scheduler：負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上；
• kubelet：負責維護容器的生命周期，同時也負責Volume（CVI）和網絡（CNI）的管理；
• Container runtime：負責鏡像管理以及Pod和容器的真正運行（CRI）；
• kube-proxy：負責為Service提供cluster內部的服務發現和負載均衡。

2.2 非核心組件

• kube-dns：負責為整個集群提供DNS服務；
• Ingress Controller：為服務提供外網入口；
• Heapster：提供資源監控；
• Dashboard：提供GUI；
• Federation：集群聯邦提供跨可用區的集群；
• Fluentd-elasticsearch：提供集群日誌採集、存儲與查詢。

延伸1：對master節點服務組件的理解：

Master節點上面主要由四個模塊組成：APIServer，schedule,controller-manager,etcd。

APIServer: APIServer負責對外提供RESTful的kubernetes API的服務，它是系統管理指令的統一接口，任何對資源的增刪該查都要交給APIServer處理后再交給etcd，如架構圖中所示，kubectl（Kubernetes提供的客戶端工具，該工具內部就是對Kubernetes API的調用）是直接和APIServer交互的。

schedule: schedule負責調度Pod到合適的Node上，如果把scheduler看成一個黑匣子，那麼它的輸入是pod和由多個Node組成的列表，輸出是Pod和一個Node的綁定,即將這個pod部署到這個Node上。Kubernetes目前提供了調度算法，但是同樣也保留了接口，用戶可以根據自己的需求定義自己的調度算法。

controller manager: 如果APIServer做的是前台的工作的話，那麼controller manager就是負責後台的。每一個資源都對應一個控制器。而control manager就是負責管理這些控制器的，比如我們通過APIServer創建了一個Pod，當這個Pod創建成功后，APIServer的任務就算完成了。而後面保證Pod的狀態始終和我們預期的一樣的重任就由controller manager去保證了。

etcd：etcd是一個高可用的鍵值存儲系統，kubernetes使用它來存儲各個資源的狀態，從而實現了Restful的API。

延伸2：對master節點服務組件的理解：

每個Node節點主要由三個模板組成：kubelet、kube-proxy、runtime。

runtime：runtime指的是容器運行環境，目前Kubernetes支持docker和rkt兩種容器。

kube-proxy: 該模塊實現了kubernetes中的服務發現和反向代理功能。kube-proxy支持TCP和UDP連接轉發，默認基於Round Robin算法將客戶端流量轉發到與service對應的一組後端pod。服務發現方面，kube-proxy使用etcd的watch機制,監控集群中service和endpoint對象數據的動態變化，並且維護一個service到endpoint的映射關係，從而保證了後端pod的IP變化不會對訪問者造成影響。另外，kube-proxy還支持session affinity。

kublet：kublet是Master在每個Node節點上面的agent，是Node節點上面最重要的模塊，它負責維護和管理該Node上的所有容器，但是如果容器不是通過kubernetes創建的，它並不會管理。本質上，它負責使Pod的運行狀態與期望的狀態一致。

三 部署規劃

3.1 節點規劃

節點	IP	類型	運行服務
k8smaster01	172.24.8.71	Kubernetes master節點	docker、etcd、kube-apiserver、kube-scheduler、kube-controller-manager、kubectl、kubelet、kube-nginx、flannel
k8smaster02	172.24.8.72	Kubernetes master節點	docker、etcd、kube-apiserver、kube-scheduler、kube-controller-manager、kubectl、 kubelet、kube-nginx、flannel
k8smaster03	172.24.8.73	Kubernetes master節點	docker、etcd、kube-apiserver、kube-scheduler、kube-controller-manager、kubectl、 kubelet、kube-nginx、flannel
k8snode01	172.24.8.74	Kubernetes node節點1	docker、etcd、kubelet、proxy、flannel
k8snode03	172.24.8.75	Kubernetes node節點2	docker、etcd、kubelet、proxy、flannel

提示：本實驗使用三節點master部署，從而實現master的高可用。

3.2 組件及版本

• Kubernetes 1.14.2
• Docker 18.09.6-ce
• Etcd 3.3.13
• Flanneld 0.11.0
• 插件：

• Coredns
• Dashboard
• Metrics-server
• EFK (elasticsearch、fluentd、kibana)

• 鏡像倉庫：

• docker registry
• harbor

3.3 組件策略

kube-apiserver：

• 使用節點本地 nginx 4 層透明代理實現高可用；
• 關閉非安全端口 8080 和匿名訪問；
• 在安全端口 6443 接收 https 請求；
• 嚴格的認證和授權策略 (x509、token、RBAC)；
• 開啟 bootstrap token 認證，支持 kubelet TLS bootstrapping；
• 使用 https 訪問 kubelet、etcd，加密通信；

kube-controller-manager：

• 3 節點高可用；
• 關閉非安全端口，在安全端口 10252 接收 https 請求；
• 使用 kubeconfig 訪問 apiserver 的安全端口；
• 自動 approve kubelet 證書籤名請求 (CSR)，證書過期后自動輪轉；
• 各 controller 使用自己的 ServiceAccount 訪問 apiserver；

kube-scheduler：

• 3 節點高可用；
• 使用 kubeconfig 訪問 apiserver 的安全端口；

kubelet：

• 使用 kubeadm 動態創建 bootstrap token，而不是在 apiserver 中靜態配置；
• 使用 TLS bootstrap 機制自動生成 client 和 server 證書，過期后自動輪轉；
• 在 KubeletConfiguration 類型的 JSON 文件配置主要參數；
• 關閉只讀端口，在安全端口 10250 接收 https 請求，對請求進行認證和授權，拒絕匿名訪問和非授權訪問；
• 使用 kubeconfig 訪問 apiserver 的安全端口；

kube-proxy：

• 使用 kubeconfig 訪問 apiserver 的安全端口；
• 在 KubeProxyConfiguration 類型的 JSON 文件配置主要參數；
• 使用 ipvs 代理模式；

集群插件：

• DNS：使用功能、性能更好的 coredns；
• Dashboard：支持登錄認證；
• Metric：metrics-server，使用 https 訪問 kubelet 安全端口；
• Log：Elasticsearch、Fluend、Kibana；
• Registry 鏡像庫：docker-registry、harbor。

四 其他準備

4.1 手動添加解析

注意：以下4.1至4.7步驟可通過如下腳本快速實現：

  1 [root@k8smaster01 ~]# vi k8sinit.sh
  2 # Modify Author: xhy
  3 # Modify Date: 2019-06-23 22:19
  4 # Version:
  5 #***************************************************************#
  6 # Initialize the machine. This needs to be executed on every machine.
  7 
  8 # Add host domain name.
  9 cat >> /etc/hosts << EOF
 10 172.24.8.71 k8smaster01
 11 172.24.8.72 k8smaster02
 12 172.24.8.73 k8smaster03
 13 172.24.8.74 k8snode01
 14 172.24.8.75 k8snode02
 15 EOF
 16 
 17 # Add docker user
 18 useradd -m docker
 19 
 20 # Disable the SELinux.
 21 sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
 22 
 23 # Turn off and disable the firewalld.
 24 systemctl stop firewalld
 25 systemctl disable firewalld
 26 
 27 # Modify related kernel parameters & Disable the swap.
 28 cat > /etc/sysctl.d/k8s.conf << EOF
 29 net.ipv4.ip_forward = 1
 30 net.bridge.bridge-nf-call-ip6tables = 1
 31 net.bridge.bridge-nf-call-iptables = 1
 32 net.ipv4.tcp_tw_recycle = 0
 33 vm.swappiness = 0
 34 vm.overcommit_memory = 1
 35 vm.panic_on_oom = 0
 36 net.ipv6.conf.all.disable_ipv6 = 1
 37 EOF
 38 sysctl -p /etc/sysctl.d/k8s.conf >&/dev/null
 39 swapoff -a
 40 sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
 41 modprobe br_netfilter
 42 
 43 # Add ipvs modules
 44 cat > /etc/sysconfig/modules/ipvs.modules <<EOF
 45 #!/bin/bash
 46 modprobe -- ip_vs
 47 modprobe -- ip_vs_rr
 48 modprobe -- ip_vs_wrr
 49 modprobe -- ip_vs_sh
 50 modprobe -- nf_conntrack_ipv4
 51 EOF
 52 chmod 755 /etc/sysconfig/modules/ipvs.modules
 53 bash /etc/sysconfig/modules/ipvs.modules
 54 
 55 # Install rpm
 56 yum install -y conntrack ntpdate ntp ipvsadm ipset jq iptables curl sysstat libseccomp wget
 57 
 58 # Create k8s directory $$ Add system PATH
 59 mkdir -p  /opt/k8s/{bin,work} /etc/{kubernetes,etcd}/cert
 60 echo 'PATH=/opt/k8s/bin:$PATH' >>/root/.bashrc
 61 source /root/.bashrc
 62 
 63 # Reboot the machine.
 64 reboot

  1 [root@k8smaster01 ~]# cat <<EOF >> /etc/hosts
  2 172.24.8.71 k8smaster01
  3 172.24.8.72 k8smaster02
  4 172.24.8.73 k8smaster03
  5 172.24.8.74 k8snode01
  6 172.24.8.75 k8snode02
  7 EOF

提示：所有節點均建議如上操作。

4.2 添加docker賬戶

  1 [root@k8smaster01 ~]# useradd -m docker

提示：所有節點均建議如上操作。

4.3 關閉SELinux

  1 [root@k8smaster01 ~]# setenforce 0
  2 [root@k8smaster01 ~]# sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config

4.4 修正iptables

  1 [root@k8smaster01 ~]# systemctl stop firewalld
  2 [root@k8smaster01 ~]# systemctl disable firewalld			#關閉防火牆
  3 [root@k8smaster01 ~]# cat <<EOF >> /etc/sysctl.d/k8s.conf
  4 net.bridge.bridge-nf-call-ip6tables = 1
  5 net.bridge.bridge-nf-call-iptables = 1
  6 net.ipv4.ip_forward = 1
  7 EOF
  8 [root@k8smaster01 ~]# modprobe br_netfilter
  9 [root@k8smaster01 ~]# sysctl -p /etc/sysctl.d/k8s.conf

提示：所有節點均建議如上操作。

4.5 關閉swap

  1 [root@k8smaster01 ~]# sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
  2 [root@k8smaster01 ~]# echo "vm.swappiness = 0" >> /etc/sysctl.d/k8s.conf	#禁止使用 swap 空間，只有當系統 OOM 時才允許使用它
  3 [root@k8smaster01 ~]# sysctl -p /etc/sysctl.d/k8s.conf

4.6 其他調整

  1 [root@k8smaster01 ~]# cat <<EOF >> /etc/sysctl.d/k8s.conf
  2 vm.overcommit_memory = 1						# 不檢查物理內存是否夠用
  3 vm.panic_on_oom = 0							# 開啟 OOM
  4 net.ipv6.conf.all.disable_ipv6 = 1					# 關閉 IPV6
  5 EOF
  6 [root@k8smaster01 ~]# sysctl -p /etc/sysctl.d/k8s.conf
  7 [root@k8smaster01 ~]# mkdir -p  /opt/k8s/{bin,work} /etc/{kubernetes,etcd}/cert	#創建相應目錄
  8 [root@k8smaster01 ~]# yum install -y conntrack ntpdate ntp ipvsadm ipset jq iptables curl sysstat libseccomp wget

提示：必須關閉 tcp_tw_recycle，否則和 NAT 衝突，會導致服務不通；

關閉 IPV6，防止觸發 docker BUG。

4.7 加載IPVS

pod的負載均衡是用kube-proxy來實現的，實現方式有兩種，一種是默認的iptables，一種是ipvs，相對iptables，ipvs有更好的性能。且當前ipvs已經加入到了內核的主幹。

為kube-proxy開啟ipvs的前提需要加載以下的內核模塊：

• ip_vs
• ip_vs_rr
• ip_vs_wrr
• ip_vs_sh
• nf_conntrack_ipv4

  1 [root@k8smaster01 ~]# cat > /etc/sysconfig/modules/ipvs.modules <<EOF
  2 #!/bin/bash
  3 modprobe -- ip_vs
  4 modprobe -- ip_vs_rr
  5 modprobe -- ip_vs_wrr
  6 modprobe -- ip_vs_sh
  7 modprobe -- nf_conntrack_ipv4
  8 EOF
  9 [root@k8smaster01 ~]# chmod 755 /etc/sysconfig/modules/ipvs.modules
 10 [root@k8smaster01 ~]# bash /etc/sysconfig/modules/ipvs.modules
 11 [root@k8smaster01 ~]# lsmod | grep -e ip_vs -e nf_conntrack_ipv4
 12 [root@k8smaster01 ~]# yum -y install ipvsadm

提示：所有節點均建議如上操作。

為了更好的管理和查看ipvs，可安裝相應的管理工具《002.LVS管理工具的安裝與使用》。

五 環境準備

5.1 配置免秘鑰

為了更方便遠程分發文件和執行命令，本實驗配置master節點到其它節點的 ssh 信任關係。

  1 [root@k8smaster01 ~]# ssh-keygen -f ~/.ssh/id_rsa -N ''
  2 [root@k8smaster01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@k8smaster01
  3 [root@k8smaster01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@k8smaster02
  4 [root@k8smaster01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@k8smaster03
  5 [root@k8smaster01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@k8snode01
  6 [root@k8smaster01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@k8snode02

提示：此操作僅需要在master節點操作。

5.2 分發集群配置參數腳本

後續使用的環境變量都定義在文件 environment.sh 中，同時拷貝到所有節點的 /opt/k8s/bin 目錄：

  1 #!/usr/bin/bash
  2 
  3 # 生成 EncryptionConfig 所需的加密 key
  4 export ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
  5 
  6 # 集群 MASTER 機器 IP 數組
  7 export MASTER_IPS=(172.24.8.71 172.24.8.72 172.24.8.73)
  8 
  9 # 集群 MASTER IP 對應的主機名數組
 10 export MASTER_NAMES=(k8smaster01 k8smaster02 k8smaster03)
 11 
 12 # 集群 NODE 機器 IP 數組
 13 export NODE_IPS=(172.24.8.74 172.24.8.75)
 14 
 15 # 集群 NODE IP 對應的主機名數組
 16 export NODE_NAMES=(k8snode01 k8snode02)
 17 
 18 # 集群所有機器 IP 數組
 19 export ALL_IPS=(172.24.8.71 172.24.8.72 172.24.8.73 172.24.8.74 172.24.8.75)
 20 
 21 # 集群所有IP 對應的主機名數組
 22 export ALL_NAMES=(k8smaster01 k8smaster02 k8smaster03 k8snode01 k8snode02)
 23 
 24 # etcd 集群服務地址列表
 25 export ETCD_ENDPOINTS="https://172.24.8.71:2379,https://172.24.8.72:2379,https://172.24.8.73:2379"
 26 
 27 # etcd 集群間通信的 IP 和端口
 28 export ETCD_NODES="k8smaster01=https://172.24.8.71:2380,k8smaster02=https://172.24.8.72:2380,k8smaster03=https://172.24.8.73:2380"
 29 
 30 # kube-apiserver 的反向代理(kube-nginx)地址端口
 31 export KUBE_APISERVER="https://127.0.0.1:8443"
 32 
 33 # 節點間互聯網絡接口名稱
 34 export IFACE="eth0"
 35 
 36 # etcd 數據目錄
 37 export ETCD_DATA_DIR="/data/k8s/etcd/data"
 38 
 39 # etcd WAL 目錄，建議是 SSD 磁盤分區，或者和 ETCD_DATA_DIR 不同的磁盤分區
 40 export ETCD_WAL_DIR="/data/k8s/etcd/wal"
 41 
 42 # k8s 各組件數據目錄
 43 export K8S_DIR="/data/k8s/k8s"
 44 
 45 # docker 數據目錄
 46 export DOCKER_DIR="/data/k8s/docker"
 47 
 48 ## 以下參數一般不需要修改
 49 
 50 # TLS Bootstrapping 使用的 Token，可以使用命令 head -c 16 /dev/urandom | od -An -t x | tr -d ' ' 生成
 51 BOOTSTRAP_TOKEN="41f7e4ba8b7be874fcff18bf5cf41a7c"
 52 
 53 # 最好使用 當前未用的網段 來定義服務網段和 Pod 網段
 54 
 55 # 服務網段，部署前路由不可達，部署後集群內路由可達(kube-proxy 保證)
 56 SERVICE_CIDR="10.254.0.0/16"
 57 
 58 # Pod 網段，建議 /16 段地址，部署前路由不可達，部署後集群內路由可達(flanneld 保證)
 59 CLUSTER_CIDR="172.30.0.0/16"
 60 
 61 # 服務端口範圍 (NodePort Range)
 62 export NODE_PORT_RANGE="30000-32767"
 63 
 64 # flanneld 網絡配置前綴
 65 export FLANNEL_ETCD_PREFIX="/kubernetes/network"
 66 
 67 # kubernetes 服務 IP (一般是 SERVICE_CIDR 中第一個IP)
 68 export CLUSTER_KUBERNETES_SVC_IP="10.254.0.1"
 69 
 70 # 集群 DNS 服務 IP (從 SERVICE_CIDR 中預分配)
 71 export CLUSTER_DNS_SVC_IP="10.254.0.2"
 72 
 73 # 集群 DNS 域名（末尾不帶點號）
 74 export CLUSTER_DNS_DOMAIN="cluster.local"
 75 
 76 # 將二進制目錄 /opt/k8s/bin 加到 PATH 中
 77 export PATH=/opt/k8s/bin:$PATH

  1 [root@k8smaster01 ~]# source environment.sh
  2 [root@k8smaster01 ~]# for all_ip in ${ALL_IPS[@]}
  3   do
  4     echo ">>> ${all_ip}"
  5     scp environment.sh root@${all_ip}:/opt/k8s/bin/
  6     ssh root@${all_ip} "chmod +x /opt/k8s/bin/*"
  7   done

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

問題

在使用自定義 Ef Core 倉儲和 ABP vNext 注入的默認倉儲時，通過兩個 Repository 進行 Join 操作，提示 Cannot use multiple DbContext instances within a single query execution. Ensure the query uses a single context instance. 。這個異常信息翻譯成中文的大概意思就是，你不能使用兩個 DbContext 裏面的 DbSet 進行 Join 查詢。

如果將自定義倉儲改為 IRepository<TEntity,TKey> 進行注入，是可以與 _courseRepostory 進行關聯查詢的。

我在 XXXEntityFrameworkCoreModule 的配置，以及自定義倉儲 EfCoreStudentRepository 代碼如下。

XXXEntityFrameworkCoreModule 代碼：

public class XXXEntityFrameworkCoreModule : AbpModule
{
    public override void ConfigureServices(ServiceConfigurationContext context)
    {
        context.Services.AddAbpDbContext<XXXDbContext>(op =>
        {
            op.AddDefaultRepositories();
        });
        
        Configure<AbpDbContextOptions>(op => op.UsePostgreSql());
    }
}

EfCoreStudentRepository 代碼：

public class EfCoreStudentRepository : EfCoreRepository<IXXXDbContext, Student, long>, IStudentRepository
{
    public EfCoreStudentRepository(IDbContextProvider<IXXXDbContext> dbContextProvider) : base(dbContextProvider)
    {
    }

    public Task<int> GetCountWithStudentlIdAsync(long studentId)
    {
        return DbSet.CountAsync(x=>x.studentId == studentId);
    }
}

原因

原因在異常信息已經說得十分清楚了，這裏我們需要了解兩個問題。

1. 什麼原因導致兩個倉儲內部的 DbContext 不一致？
2. 為什麼 ABP vNext 自己實現的倉儲能夠進行關聯查詢呢？

首先我們得知道，倉儲內部的 DbContext是怎麼獲取的。我們的自定義倉儲都會繼承 EfCoreRepository ，而這個倉儲是實現了 IQuerable<T> 接口的，最終它會通過一個 IDbContextProvider<TDbContext> 獲得一個可用的 DbContext 。

public class EfCoreRepository<TDbContext, TEntity> : RepositoryBase<TEntity>, IEfCoreRepository<TEntity>
    where TDbContext : IEfCoreDbContext
    where TEntity : class, IEntity
{
    public virtual DbSet<TEntity> DbSet => DbContext.Set<TEntity>();

    DbContext IEfCoreRepository<TEntity>.DbContext => DbContext.As<DbContext>();

    // 這裏可以看到，是通過 IDbContextProvider 來獲得 DbContext 的。
    protected virtual TDbContext DbContext => _dbContextProvider.GetDbContext();

    protected virtual AbpEntityOptions<TEntity> AbpEntityOptions => _entityOptionsLazy.Value;

    private readonly IDbContextProvider<TDbContext> _dbContextProvider;
    private readonly Lazy<AbpEntityOptions<TEntity>> _entityOptionsLazy;

    // ... 其他代碼。
}

下面就是 IDbContextProvider<TDbContext> 內部的核心代碼：

public class UnitOfWorkDbContextProvider<TDbContext> : IDbContextProvider<TDbContext> where TDbContext : IEfCoreDbContext
{
    private readonly IUnitOfWorkManager _unitOfWorkManager;
    private readonly IConnectionStringResolver _connectionStringResolver;

    // ... 其他代碼。

    public TDbContext GetDbContext()
    {
        var unitOfWork = _unitOfWorkManager.Current;
        if (unitOfWork == null)
        {
            throw new AbpException("A DbContext can only be created inside a unit of work!");
        }

        var connectionStringName = ConnectionStringNameAttribute.GetConnStringName<TDbContext>();
        var connectionString = _connectionStringResolver.Resolve(connectionStringName);

        // 會構造一個 Key，而這個 Key 剛好是泛型類型的 FullName。
        var dbContextKey = $"{typeof(TDbContext).FullName}_{connectionString}";

        // 內部是從一個字典當中，根據 dbContextKey 獲取 DbContext。如果不存在的話則調用工廠方法創建一個新的 DbContext。
        var databaseApi = unitOfWork.GetOrAddDatabaseApi(
            dbContextKey,
            () => new EfCoreDatabaseApi<TDbContext>(
                CreateDbContext(unitOfWork, connectionStringName, connectionString)
            ));

        return ((EfCoreDatabaseApi<TDbContext>)databaseApi).DbContext;
    }

    // ... 其他代碼。
}

通過以上代碼我們就可以知道，ABP vNext 在倉儲的內部是通過 IDbContextProvider<TDbContext> 中的 TDbContext 泛型，來確定是否構建一個新的 DbContext 對象。

不論是 ABP vNext 針對 IRepository<TEntity,TKey> ，還是我們自己實現的自定義倉儲，它們最終的實現都是基於 EfCoreRepository<TDbContext,TEntity,TKey> 的。而我們 IDbContextProvider<TDbContext> 的泛型，也是這個倉儲基類提供的，後者的 TDbContext 就是前者的泛型參數。

所以當我們在模塊添加 DbContext 的過城中，只要調用了 AddDefaultRepositories() 方法，ABP vNext 就會遍歷你提供的 TDbContext 所定義的實體，然後為這些實體建立默認的倉儲。

在注入倉儲的時候，找到了獲得默認倉儲實現類型的方法，可以看到這裏它使用的是 DefaultRepositoryDbContextType 作為默認的 TDbContext 類型。

protected virtual Type GetDefaultRepositoryImplementationType(Type entityType)
{
    var primaryKeyType = EntityHelper.FindPrimaryKeyType(entityType);

    // 重點在於構造倉儲類型時，傳遞的 Options.DefaultRepositoryDbContextType 參數，這個參數就是後面 EfCoreRepository 的 TDbContext 泛型。
    if (primaryKeyType == null)
    {
        return Options.SpecifiedDefaultRepositoryTypes
            ? Options.DefaultRepositoryImplementationTypeWithoutKey.MakeGenericType(entityType)
            : GetRepositoryType(Options.DefaultRepositoryDbContextType, entityType);
    }

    return Options.SpecifiedDefaultRepositoryTypes
        ? Options.DefaultRepositoryImplementationType.MakeGenericType(entityType, primaryKeyType)
        : GetRepositoryType(Options.DefaultRepositoryDbContextType, entityType, primaryKeyType);
}

最後我發現這個就是在模塊調用 AddAbpContext<TDbContext> 所提供的泛型參數。

public abstract class AbpCommonDbContextRegistrationOptions : IAbpCommonDbContextRegistrationOptionsBuilder
{
    // ... 其他代碼

    protected AbpCommonDbContextRegistrationOptions(Type originalDbContextType, IServiceCollection services)
    {
        OriginalDbContextType = originalDbContextType;
        Services = services;
        DefaultRepositoryDbContextType = originalDbContextType;
        CustomRepositories = new Dictionary<Type, Type>();
        ReplacedDbContextTypes = new List<Type>();
    }

    // ... 其他代碼
}

public class AbpDbContextRegistrationOptions : AbpCommonDbContextRegistrationOptions, IAbpDbContextRegistrationOptionsBuilder
{
    public Dictionary<Type, object> AbpEntityOptions { get; }

    public AbpDbContextRegistrationOptions(Type originalDbContextType, IServiceCollection services)
        : base(originalDbContextType, services) // 之類調用的就是上面的構造方法。
    {
        AbpEntityOptions = new Dictionary<Type, object>();
    }
}

public static class AbpEfCoreServiceCollectionExtensions
{
    public static IServiceCollection AddAbpDbContext<TDbContext>(
        this IServiceCollection services, 
        Action<IAbpDbContextRegistrationOptionsBuilder> optionsBuilder = null)
        where TDbContext : AbpDbContext<TDbContext>
    {
        // ... 其他代碼。
        
        var options = new AbpDbContextRegistrationOptions(typeof(TDbContext), services);

        // ... 其他代碼。

        return services;
    }
}

所以，我們的默認倉儲的 dbContextKey 是 XXXDbContext，我們的自定義倉儲繼承 EfCoreRepository<IXXXDbContext,TEntity,TKey> ，所以它的 dbContextKey 就是 IXXXDbContext 。所以自定義倉儲獲取到的 DbContext 就與自定義倉儲的不一致了，從而提示上述異常。

解決

找到自定自定義倉儲的定義，修改它 EfCoreReposiotry<TDbContext,TEntity,TKey> 的 TDbContext 泛型參數，變更為 XXXDbContext 即可。

public class EfCoreStudentRepository : EfCoreRepository<XXXDbContext, Student, long>, IStudentRepository
{
    public EfCoreStudentRepository(IDbContextProvider<XXXDbContext> dbContextProvider) : base(dbContextProvider)
    {
    }

    public Task<int> GetCountWithStudentlIdAsync(long studentId)
    {
        return DbSet.CountAsync(x=>x.studentId == studentId);
    }
}

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※南投搬家前需注意的眉眉角角，別等搬了再說!