基於Spring Cloud的微服務落地

来源:https://www.cnblogs.com/lfs2640666960/archive/2018/04/20/8893987.html
-Advertisement-
Play Games

微服務架構模式的核心在於如何識別服務的邊界，設計出合理的微服務。但如果要將微服務架構運用到生產項目上，並且能夠發揮該架構模式的重要作用，則需要微服務框架的支持。 在Java生態圈，目前使用較多的微服務框架就是集成了包括Netfilix OSS以及Spring的Spring Cloud。它包括： Sp ...


微服務架構模式的核心在於如何識別服務的邊界，設計出合理的微服務。但如果要將微服務架構運用到生產項目上，並且能夠發揮該架構模式的重要作用，則需要微服務框架的支持。

在Java生態圈，目前使用較多的微服務框架就是集成了包括Netfilix OSS以及Spring的Spring Cloud。它包括：

  • Spring Cloud Config：配置管理工具，支持使用Git存儲配置內容，可以實現應用配置的外部化存儲，支持客戶端配置信息刷新、加密/解密配置內容等。
  • Spring Cloud Netflix：對Netflix OSS進行了整合。其中又包括：
    • Eureka：服務治理組件，包含服務註冊中心、服務註冊與發現。
    • Hystrix：容器管理組件，實現斷路器模式，倘若依賴的服務出現延遲或故障，則提供強大的容錯功能。
    • Ribbon：客戶端負載均衡的服務調用組件。
    • Feign：基於Ribbon和Hystrix的聲明式服務調用組件。
    • Zuul：網關組件，提供智能路由、訪問過濾等功能。
    • Archaius：外部化配置組件。
  • Spring Cloud Bus：事件、消息匯流排。
  • Spring Cloud Cluster：針對ZooKeeper、Redis、Hazelcast、Consul的選舉演算法和通用狀態模式的實現。
  • Spring Cloud Cloudfoundry：與Pivotal Cloudfoundry的整合支持。
  • Spring Cloud Consul：服務發現與配置管理工具。
  • Spring Cloud Stream：通過Redis、Rabbit或者Kafka實現的消息驅動的微服務。
  • Spirng Cloud AWS：簡化和整合Amazon Web Service。
  • Spring Cloud Security：安全工具包，提供Zuul代理中對OAuth2客戶端請求的中繼器。
  • Spring Cloud Sleuth：Spring Cloud應用的分散式跟蹤實現，可以整合Zipkin。
  • Spring Cloud ZooKeeper：基於ZooKeeper的服務發現與配置管理組件。
  • Spring Cloud Starters：Spring Cloud的基礎組件，是基於Spring Boot風格項目的基礎依賴模塊。
  • Spring Cloud CLI：用於在Groovy中快速創建Spring Cloud應用的Spring Boot CLI插件。

服務治理

當一個系統的微服務數量越來越多的時候，我們就需要對服務進行治理，提供統一的服務註冊中心，然後在其框架下提供發現服務的功能。這樣就避免了對多個微服務的配置，以及微服務之間以及與客戶端之間的耦合。

Spring Cloud Eureka是對Netflix Eureka的包裝，用以實現服務註冊與發現。Eureka服務端即服務註冊中心，支持高可用配置。它依托於強一致性提供良好的服務實例可用性，並支持集群模式部署。Eureka客戶端則負責處理服務的註冊與發現。客戶端服務通過annotation與參數配置的方式，嵌入在客戶端應用程式代碼中。在運行應用程式時，Eureka客戶端向註冊中心註冊自身提供的服務，並周期性地發送心跳更新它的服務租約。

搭建服務註冊中心

服務註冊中心是一個獨立部署的服務（你可以認為它也是一個微服務），所以需要單獨為它創建一個項目，併在pom.xml中添加Eureka的依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>

創建Spring Boot Application：

@EnableEurekaServer
@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        new SpringApplicationBuilder(Application.class).web(true).run(args);
    }
}

註冊服務提供者

要讓自己編寫的微服務能夠註冊到Eureka伺服器中，需要在服務的Spring Boot Application中添加 @EnableDiscoveryClient 註解，如此才能讓Eureka伺服器發現該服務。當然，pom.xml文件中也需要添加相關依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>

同時，我們還需要為服務命名，並指定地址。這些信息都可以在application.properties配置文件中配置：

spring.application.name=demo-service

eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/

說明：Spring更推薦使用yml文件來維護系統的配置，yml文件可以體現出配置節的層次關係，表現力比單純的key-value形式更好。如果結合使用後面講到的Spring Cloud Config，則客戶端的配置文件必須命名為bootstrap.properties或者bootstrap.yml。與上述配置相同的yml文件配置為：

spring:
  application:
    name: demo-service

eureka:
  client:
    serviceUrl: 
      defaultZone: http://localhost:1111/eureka/

服務發現與消費

在微服務架構下，許多微服務可能會扮演雙重身份。一方面它是服務的提供者，另一方面它又可能是服務的消費者。註冊在Eureka Server中的微服務可能會被別的服務消費。此時，就相當於在服務中創建另一個服務的客戶端，並通過RestTemplate發起對服務的調用。為了更好地提高性能，可以在服務的客戶端引入Ribbon，作為客戶端負載均衡。

現在假定我們要為demo-service創建一個服務消費者demo-consumer。該消費者自身也是一個Spring Boot微服務，同時也能夠被Eureka伺服器註冊。這時，就需要在該服務的pom.xml中添加eureka與ribbon的依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-ribbon</artifactId>
</dependency>

然後在主應用類 ConosumerApplication 中註入 RestTemplate ，並引入 @LoadBalanced 註解開啟客戶端負載均衡：

@EnableDiscoveryClient
@SpringBootApplication
public class ConsumerApplication {
    @Bean
    @LoadBalanced
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args)
    }
}

假設消費demo-service的客戶端代碼寫在demo-consumer服務的其中一個Controller中：

@RestController
public class ConsumerController {
    @Autowired
    RestTemplate restTemplate;

    @RequestMapping(value = "/demo-consumer", method = RequestMethod.Get)
    public String helloConsumer() {
        return restTemplate.getForEntity("http://demo-service/demo", String.class).getBody(); 
    }
}

通過 RestTemplate 就可以發起對demo-service的消費調用。

聲明式服務調用

通過Ribbon和Hystrix可以實現對微服務的調用以及容錯保護，但Spring Cloud還提供了另一種更簡單的聲明式服務調用方式，即Spring Cloud Feign。Feign實際上就是對Ribbon與Hystrix的進一步封裝。通過Feign，我們只需創建一個介面並用annotation的方式配置，就可以完成對服務供應方的介面（REST API）綁定。

假設我們有三個服務：

  • Notification Service
  • Account Service
  • Statistics Service

服務之間的依賴關係如下圖所示：

要使用Feign來完成聲明式的服務調用，需要在作為調用者的服務中創建Client。Client通過Eureka Server調用註冊的對應服務，這樣可以解除服務之間的耦合。結構如下圖所示：

為了使用Feign，需要對應微服務的pom.xml文件中添加如下依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-feign</artifactId>
</dependency>

同時，還需要在被消費的微服務Application中添加 @EnableFeignClients 註解。例如在Statistics服務的應用程式類中：

@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients
public class StatisticsApplication {
    public static void main(String[] args) {
        SpringApplication.run(StatisticsApplication.class, args);
    }
}

由於Account服務需要調用Statistics服務，因此需要在Account服務項目中增加對應的client介面：

@FeignClient(name = "statistics-service")
public interface StatisticsServiceClient {

    @RequestMapping(method = RequestMethod.PUT, value = "/statistics/{accountName}", consumes = MediaType.APPLICATION_JSON_UTF8_VALUE)
    void updateStatistics(@PathVariable("accountName") String accountName, Account account);

}

StatisticsServiceClient介面的 updateStatistics() 方法會調用URI為 /statistics/{accountName} 的REST服務，且HTTP動詞為put。這個服務其實對應就是Statistics Service中StatisticsController類中的 saveStatistics() 方法：

@RestController
public class StatisticsController {

    @Autowired
    private StatisticsService statisticsService;

    @RequestMapping(value = "/{accountName}", method = RequestMethod.PUT)
    public void saveStatistics(@PathVariable String accountName, @Valid @RequestBody Account account) {
        statisticsService.save(accountName, account);
    }
}

在Account服務中，如果要調用Statistics服務，都應該通過StatisticsServiceClient介面進行調用。例如，Account服務中的AccountServiceImpl要調用 updateStatistics() 方法，就可以在該類的實現中通過 @autowired 註入StatisticsServiceClient介面：

@Service
public class AccountServiceImpl implements AccountService {
    @Autowired
    private StatisticsServiceClient statisticsClient;

    @Autowired
    private AccountRepository repository;

    @Override
    public void saveChanges(String name, Account update) {

        //...
        statisticsClient.updateStatistics(name, account);
    }
}

Notification服務對Account服務的調用如法炮製。

服務容錯保護

在微服務架構中，微服務之間可能存在依賴關係，例如Notification Service會調用Account Service，Account Service調用Statistics Service。真實產品中，微服務之間的調用會更加尋常。倘若上游服務出現了故障，就可能會因為依賴關係而導致故障的蔓延，最終導致整個系統的癱瘓。

Spring Cloud Hystrix通過實現斷路器（Circuit Breaker）模式以及線程隔離等功能，實現服務的容錯保護。

仍然參考前面的例子。現在系統的微服務包括：

  • 上游服務：demo-service
  • 下游服務：demo-consumer
  • Eureka伺服器：eureka-server

假設上游服務可能會出現故障，為保證系統的健壯性，需要在下游服務中加入容錯包含功能。首先需要在demo-consumer服務中添加對hystrix的依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

然後在demo-consumer的應用程式類中加入 @EnableCircuitBreaker 開啟斷路器功能：

@EnableCircuitBreaker
@EnableDiscoveryClient
@SpringBootApplication
public class ConsumerApplication {
    @Bean
    @LoadBalanced
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args)
    }
}

註意：Spring Cloud提供了 @SpringCloudApplication 註解簡化如上代碼。該註解事實上已經包含了前面所述的三個註解。 @SpringCloudApplication 註解的定義如下所示：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public @interface SpringCloudApplication {}

接下來，需要引入一個新的服務類來封裝hystrix提供的斷路器保護功能，主要是定義當故障發生時需要執行的回調邏輯，即代碼中指定的fallbackMethod：

@Service
public class ConsumerService {
    @Autowired
    RestTemplate restTemplate;

    @HystrixCommand(fallbackMethod = "consumerFallback")
    public String consume() {
        return restTemplate.getForEntity("http://demo-service/demo", String.class).getBody(); 
    }

    public String consumerFallback() {
        return "error";
    }
}

@RestController
public class ConsumerController {
    @Autowired
    ConsumerService consumerService;

    @RequestMapping(value = "/demo-consumer", method = RequestMethod.Get)
    public String helloConsumer() {
        return consumerService.consume(); 
    }
}

服務監控

微服務架構將服務的粒度分解的足夠細，這使得它在保證服務足夠靈活、足夠獨立的優勢下，也帶來了管理和監控上的挑戰，服務與服務之間的依賴也變得越來越複雜。因此，對服務健康度和運行指標的監控就變得非常重要。

Hystrix提供了Dashboard用以監控Hystrix的各項指標信息。為了監控整個系統的微服務，我們需要為Hystrix Dashboard建立一個Spring Boot微服務。在該服務項目的pom文件中，添加如下依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-actuator</artifactId>
</dependency>

服務的Application類需要添加 @EnableHystrixDashboard ，以啟用Hystrix Dashboard功能。同時，可能需要根據實際情況修改application.properties配置文件，例如選擇可用的埠號等。

如果要實現對集群的監控，則需要加入Turbine。

API網關

理論上，客戶端可以直接向每個微服務直接發送請求。但是這種方式是存在挑戰和限制的，調用者需要知道所有端點的地址，分別對每一段信息執行http請求，然後將結果合併到客戶端。

一般而言，針對微服務架構模式的系統，採用的都是 前後端分離 的架構。為了明顯地隔離開前端與後端的邊界，我們通常可以專門為前端的消費者定義更加粗粒度的Open Service。這些Open Service是對外的RESTful API服務，可以通過F5、Nginx等網路設備或工具軟體實現對各個微服務的路由與負載均衡，並公開給外部的客戶端調用（註意，內部微服務之間的調用並不需要通過Open Service）。這種對外公開的Open Service通常又被稱為邊緣服務（edge service）。

如果這些Open Service需要我們自己去開發實現併進行服務的運維，在系統規模不斷增大的情況下，會變得越來越困難。例如，當增加了新的微服務又或者IP地址發生變動時，都需要運維人員手工維護這些路由規則與服務實例列表。又例如針對所有垂直分隔的微服務，不可避免存在重用的橫切關註點，例如用戶身份認證、授權或簽名校驗等機制。我們不能在所有微服務中都去添加這些相同的功能，因為這會造成橫切關註點的冗餘。

解決的辦法是引入API網關（API Gateway）。它是系統的單個入口點，用於通過將請求路由到適當的後端服務或者通過調用多個後端服務並聚合結果來處理請求。此外，它還可以用於認證、insights、壓力測試、金絲雀測試（canary testing）、服務遷移、靜態響應處理和主動變換管理。Spring Cloud為API網關提供的解決方案就是Spring Cloud Zuul，它是對Netflix Zuul的包裝。

路由規則與服務實例維護

Zuul解決路由規則與服務實例維護的方法是通過Spring Cloud Eureka。API Gateway自身就是一個Spring Boot服務，該服務自身被註冊為Eureka服務治理下的應用，同時它會從Eureka中獲得所有其他微服務的實例信息。這樣的設計符合DRY原則，因為Eureka已經維護了一套服務實例信息，Zuul直接重用了這些信息，無需人工介入。

對於路由規則，Zuul預設會將服務名作為ContextPath創建路由映射，基本上這種路由映射機制就可以滿足微服務架構的路由需求。倘若需要一些特殊的配置，Zuul也允許我們自定義路由規則，可以通過在API網關的Application類中創建PatternServiceRouteMapper來定義自己的規則。

橫切關註點

諸如授權認證、簽名校驗等業務邏輯本身與微服務應用所要處理的業務邏輯沒有直接關係，我們將這些可能橫跨多個微服務的功能稱為“橫切關註點”。這些橫切關註點往往會作為“裝飾”功能在服務方法的前後被調用。Spring Cloud Zuul提供了一套 過濾器機制 ，允許開發者創建各種過濾器，並指定哪些規則的請求需要執行哪個過濾器。

自定義的過濾器繼承自ZuulFilter類。例如我們要求客戶端發過來的請求在路由之前需要先驗證請求中是否包含accessToken參數，如果有就進行路由，否則就拒絕，並返回401 Unauthorized錯誤，則可以定義AccessFilter類：

public class AccessFilter extends ZuulFilter {
    private static Logger log = LoggerFactory.getLogger(AccessFilter.class);

    @Override
    public String filterType() {
        return "pre"
    }

    @Override
    public int filterOrder() {
        return 0;
    }

    @Override
    public boolean shouldFilter() {
        return true;
    }
    
    @Override
    public Object run() {
        RequestContext ctx = RequestContext.getCurrentContext();
        HttpServletRequest request = ctx.getRequest();
        
        log.info("send {} request to {}", request.getMethod(), request.getRequestURL().toString());

        Object accessToken = request.getParameter("accessToken");
        if (accessToken == null) {
            log.warn("access token is empty");
            ctx.setSendZuulResponse(false);
            ctx.setResponseStatusCode(401);
            return null;
        }
        log.info("access token ok");
        return null;
    }
}

要讓該自定義過濾器生效，還需要在Zuul服務的Application中創建具體的Bean：

@EnableZuulProxy
@SpringCloudApplication
public class ZuulApplication {
    public static void main(String[] args) {
        new SpringApplicatonBuilder(ZuulApplication.class).web(true).run(args);
    }

    @Bean
    public AccessFilter accessFilter() {
        return new AccessFilter();
    }
}

Zuul一共提供了四種過濾器：

  • pre filter
  • routing filter
  • post filter
  • error filter

下圖來自官網，它展現了客戶端請求到達Zuul API網關的生命周期與過濾過程：

通過starter添加Zuul的依賴時，自身包含了spring-cloud-starter-hystrix與spring-cloud-starter-ribbon模塊的依賴，因此Zuul自身就擁有線程隔離與斷路器的服務容錯功能，以及客戶端負載均衡。但是，倘若我們使用path與url的映射關係來配置路由規則，則路由轉發的請求並不會採用HystrixCommand來包裝，因而這類路由是沒有服務容錯與客戶端負載均衡作用的。所以在使用Zuul時，應儘量使用path和serviceId的組合對路由進行配置。

微服務技術是程式員繞不開的話題，想要瞭解更多微服務架構知識點的，可以關註我一下，我後續也會整理更多關於微服務架構這一塊的知識點分享出來，另外順便給大家推薦一個交流學習群：650385180，裡面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分散式、微服務架構的原理，JVM性能優化這些成為架構師必備的知識體系。

分散式配置中心

為什麼要引入一個分散式配置中心？一個微服務就需要至少一個配置文件，怎麼管理分散在各個微服務中的配置文件呢？如果微服務採用的是不同的技術棧，如何來統一微服務的配置呢？微服務是部署在不同的節點中，顯然我們無法在單機中實現對分散式節點的配置管理。這就是引入Spring Cloud Config的目的。

Spring Cloud Config提供了服務端和客戶端支持。服務端是一個獨立的微服務，同樣可以註冊到Eureka伺服器中。每個需要使用分散式配置中心的微服務都是Spring Cloud Config的客戶端。Spring Cloud Config預設實現基於Git倉庫，既可以進行版本管理，還可以通過本地Git庫起到緩存作用。Spring Cloud Config不限於基於Spring Cloud開發的系統，而是可以用於任何語言開發的程式，並支持自定義實現。

配置中心服務端

Spring Cloud Config Server作為配置中心服務端，提供如下功能：

  • 拉取配置時更新git倉庫副本，保證是最新結果
  • 支持數據結構豐富，yml, json, properties等
  • 配合Eureke可實現服務發現，配合cloud bus可實現配置推送更新
  • 配置存儲基於git倉庫，可進行版本管理
  • 簡單可靠，有豐富的配套方案

建立一個Config服務，需要添加如下依賴：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

服務的Application類需要添加 @EnableConfigServer 註解：

@SpringBootApplication
@EnableConfigServer
public class ConfigApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigApplication.class, args);
    }
}

配置服務的基本信息和Git倉庫的信息放在application.yml文件中：

spring:
  cloud:
    config:
      server:
        git:
            uri: http://localhost/workspace/springcloud-demo
            username: user
            password: password

server:
  port: 8888

security:
  user:
    password: ${CONFIG_SERVICE_PASSWORD}

Git庫與配置服務

在Config服務中配置了Git伺服器以及Git庫的信息後，我們就可以在git庫中提交配置文件。存儲在git庫中配置文件的名字以及分支名（預設為master分支）會組成訪問Config服務的URI。假設有一個服務為Notification服務，則它在配置中心服務端的配置文件為notification-dev.yml，內容如下：

devMode:  true
spring:
    application:
        name: notification
    jdbc:
        host: localhost
        port: 3306
        user: root
        password: 123456
logging:
    file: demo

配置中心客戶端

需要讀取配置中心服務端信息的微服務都是配置中心的客戶端，為了能夠讀取配置服務端的信息，這些微服務需要：

  • 在pom中添加對spring-cloud-starter-config的依賴
  • 在bootstrap.properties或者bootstrap.yml中配置獲取配置的config-server位置

例如，Account服務的配置是由Spring Cloud Config進行管理的。在它的資源目錄下，提供了bootstrap.yml配置文件，內容如下所示：

spring:
  application:
    name: account-service
  cloud:
    config:
      uri: http://config:8888
      fail-fast: true
      password: ${CONFIG_SERVICE_PASSWORD}
      username: user

註意，該配置文件除了配置了該Account服務應用的name之外，主要是支持該應用獲得配置服務端的信息。微服務自身的配置信息則統一放到配置中心服務端的文件中，並由Git庫進行管理。例如，Account服務的詳細配置在配置中心服務端的account-dev.yml文件中：

security:
  oauth2:
    client:
      clientId: account-service
      clientSecret: ${ACCOUNT_SERVICE_PASSWORD}
      accessTokenUri: http://auth-service:5000/uaa/oauth/token
      grant-type: client_credentials
      scope: server

spring:
  data:
    mongodb:
      host: account-mongodb
      username: user
      password: ${MONGODB_PASSWORD}
      database: piggymetrics
      port: 27017

server:
  context-path: /accounts
  port: 6000

Spring Cloud Config通過Git實現分散式的配置管理。當配置中心服務端的配置信息發生變更時，各個作為配置客戶端的微服務會向Git庫提交pull更新，獲得最新的配置信息。

當然，Spring Cloud Config還可以使用SVN庫進行配置管理，也支持簡單的本地文件系統的存儲方式。此時需要將 spring.profiles.active 設置為native，並設置搜索配置文件的路徑。如果不配置路徑，預設在 src/main/resources 目錄下搜索。如下配置文件：

spring:
  cloud:
    config:
      server:
        native:
          search-locations: classpath:/shared
  profiles:
    active: native

搜索路徑放在classpath下的shared目錄下，那麼在代碼中，目錄就是 resources/shared 。如果使用本地文件系統管理配置文件，則無法支持分散式配置管理以及版本管理，因此在生產系統下，還是推薦使用Git庫的方式。

總結

在實施微服務時，我們可以將微服務視為兩個不同的邊界。一個是與前端UI的通信，稱為Open Service（Edge Service），通過引入API Gateway來實現與前端UI的通信。另一個是在邊界內業務微服務之間的通信，通過Feign實現微服務之間的協作。所有的微服務都會通過Eureka來完成微服務的註冊與發現。一個典型的基於Spring Cloud的微服務架構如下所示：

微服務的集成可以通過Feign+Ribbon以RESTful方式實現通信，也可以基於RPC方式（可以結合Protocol Buffer）完成服務之間的通信，甚至可以通過發佈事件與訂閱事件的機制。事件機制可以使微服務之間更加鬆散耦合。這時，我們可以引入RabbitMQ或Kafka來做到服務與服務之間的解耦。事件機制是非同步和非阻塞的，在某些業務場景下，它的性能會更加的好。Spring Cloud也提供了相關的組件Spring Cloud Stream來支持這種事件機制。

對於微服務之間的協作，到底選擇Feign這種REST方式、事件機制或者RPC方式，取決於業務場景是否需要同步方式，還是非同步方式；是高性能高併發，還是普通方式；是要求徹底解耦，還是做到一般的鬆散耦合。我們需要針對實際情況作出實際的判斷，作出正確的選擇。沒有誰壞誰好之分，而是看誰更加的適合。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類