微服务架构风格

微服务架构风格是一种将单一应用程序开发转化成一组小型服务开发的方法,每个服务运行在自己的进程中,服务器间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务公用一个最小型的集中式的管理,服务可用不同的语言开发,并且可以使用不同的数据存储技术。

单体架构与微服务架构

单体架构

优点

  • 开发简单:所有东西全都写在同一个服务中,不需要考虑拆分。
  • 部署傻瓜:每次升级,只会升级一个大的包。

缺点

  • 部署频率低:因为每次升级都是全量升级,所以升级的频率不可避免的降低。
  • 部署风险高:同上,全量升级风险高。
  • 无法按需扩展:如果系统中某个服务达到性能瓶颈,只能在另外一个服务器中再部署一个同样的系统。只是为了提升某个服务的性能,把全部服务都部署一套,不可避免的浪费资源。
  • 某个模块达到性能瓶颈后,要重构就是重构整个项目。

微服务架构

  • 每个微服务可独立运行在自己的进程中
  • 一系列独立运行的微服务共同构建起整个系统
  • 每个微服务是独立的业务开发,只关注某个特定的功能
  • 全自动机制(CI/CD)
  • 异构(不同语言与数据存储)
  • 轻量的通信机制

微服务架构核心思想

分而治之。

微服务架构通览

每一个微服务都是一个单体应用。

微服务适用场景

  • 大型复杂应用
  • 高并发、高负载应用
  • 快速迭代

微服务拆分方法

领域驱动设计(英语:Domain-driven design,缩写 DDD)

DDD是由Eric Evans最先提出,目的是对软件所涉及到的领域进行建模,以应对系统规模过大时引起的软件复杂性的问题。整个过程大概是这样的,开发团队和领域专家一起通过通用语言(Ubiquitous Language)去理解和消化领域知识,从领域知识中提取和划分为一个一个的子领域(核心子域,通用子域,支撑子域),并在子领域上建立模型,再重复以上步骤,这样周而复始,构建出一套符合当前领域的模型。

面向对象(状态和行为)

by name,by verb.

按照职责划分

按通用性划分

用户中心、认证授权、中台战略

微服务拆分粒度

  • 良好的满足业务需求
  • 增量迭代,微服务间相互独立
  • 持续进化,技术重构(进化),技术的更替
  • 团队的幸福感,每次迭代升级压力可控

微服务拆分是 动态 的!

拆分 -> 建表 -> 写代码

课程微服务在Controller中使用RestTemplate调用用户微服务提供的接口。

@EnableCaching
@EnableScheduling
@SpringBootApplication
public class ZhibeiApplication {

    @PostConstruct
    void started() {
        // 设置时区为东八区
        TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"));
        // TimeZone.setDefault(TimeZone.getTimeZone("GMT+8"));
    }

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

    @Bean
    public RestTemplate createRestTemplate() {
        return new RestTempalte();
    }

}