软件架构进化，我的经历:

  • 一层架构
  • MVC (ssh, ssm)
  • dubbo (分离前后端，单体变2个)

上面都是单体架构，而且现实中大多数公司也都还在用单体架构

单体架构

单体架构: 功能，业务集中在一个发布包中，部署运行在同一个进程中;

优势: 易于开发，测试，部署，水平伸缩

现在的缺点:

  • 代码膨胀，难以维护
  • CD交付周期长; 构建、部署成本大
  • 新人上手周期过长(说的就是我…)
  • 创新困难
  • 可扩展性差(一个进程，无论是垂直扩展增强载体机器性能，还是水平扩展增大/强集群性能，都很贵)

微服务特征

  • 单一职责
  • 轻量级通信
  • 隔离性
  • 每个微服务有自己的存储系统
  • 技术多样性, 只要能提供API即可

诞生背景

  • 容器技术成熟
  • 敏捷开发, 精益方法 (频繁修改，开发，测试，上线)

e.g. 项目架构

1
2
3
4
5
6
7
8
Client:                            
                        ---> REST API| Container(登录注册MS) -- DB  (QPS: 40, use 2 containers)
PC                     |              
                       |---> REST API| Container(用户信息MS) -- DB  (QPS: 100, use 5) etc.
iOS   ---> ApiGateway->|
                       |---> REST API| Container(邮件短信MS) -- DB
Android                |
                        ---> REST API| Container(课程 MS) -- DB

注:

  1. 并不是所有的微服务都能提供REST API, 这里只是举个例子，假设这里所有的微服务都暴露接口
  2. 上面各个微服务之间可以通讯，这里没有画出来

网关

并不是所有的微服务都需要，或者都能，提供REST API;

提供REST API:表明是基于HTTP通信的, 但是有的可能是基于RPC,或者Dubbo, Thrift,还可能是基于MQ的;

所以需要网关。网关还可能有其他的功能，比如授权，监控，负载均衡，缓存, etc.

注: HTTP并不等于REST, HTTP是一个属于应用层的协议，REST是一种风格

微服务的划分

DDD: Domain Driven Design: 精细划分微服务各个服务的界限

之前看的DDD关于MVC三层架构的划分，DDD精髓在于领域模型准确反映了业务语言; 我的理解: 所以不用思考是用 controller还是service来写业务逻辑, 而是写在repository中, 也就是之前考虑的dao层中本身就包含业务逻辑

微服务架构引入的问题

  1. 微服务之间如何通讯?
    • 单体架构中没有这个问题，因为都在一台机器/一个集群上
  2. 微服务如何发现彼此?
    • 单体架构中只有Dubbo有这个问题: Dubbo中是用ZK解决的，ZK作为中间人，web端(消费端)向中间人要这个服务，服务端把服务传给ZK
    • 除了ZK之外，还有Eureka, etcd, Consul, etc.
  3. 微服务怎样部署？更新？扩容？
    • 单体架构中，各个公司有差异，原始的可能用FTP修改重启，自动化的可能e.g. Jenkins从master拉取，在预发环境，编译环境中改写然后脚本直接同步到生产环境，重启;
    • 微服务数量庞大，可能一个功能需要100+个微服务同时修改上线，手动上线更新是不可能的，所以要用服务编排框架