序言

这篇文章应该是一个聚合中心，把我的知识、经验和思考都汇集在这里。同时也是一个参考书，把相关的知识关联起来。

系统架构设计目标

系统架构设计的目标是设计出一个“好”的系统。但是对于“好”的定义是什么，是至关重要的。

什么是一个好的系统

我们需要的好的系统的特性列举如下：

  1. 业务峰值期能够弹性扩容；
  2. 出现问题可以快速定位；
  3. 系统运行时可以获得总体及系统各个部分的各项运行指标；
  4. 能够灰度发布；
  5. 能够按照负载均衡和限流需求进行流量分发；
  6. 支持CI/CD，加上单元测试、代码扫描等质量保证手段。

还有一点重要的是：没有绝对的标准，一定要根据业务本身需求来思考系统技术架构。

  • “脱离业务本身谈架构是没有意义的”
  • “脱离团队的实际情况谈架构也是没有意义的”
  • “脱离历史遗留问题和现阶段情况，谈架构同样是没有意义的”

打个比方，假设你有了航母、飞机、坦克，和大量专业的军官和高素质的士兵，并拥有充足的后勤保障，去打一场灭国战争。其打法跟你只有小米加步枪，和几个月前还在种地的刚入伍的士兵，去打一场为了保存星星之火的游击战争的打法，两者一定是不一样的。

那么一个好的系统架构，一般来说，应该符合几个条件：

  1. 好的系统架构应该是可以演化的，因为事物是在发展的，绝对不能僵化；
  2. 好的系统架构应该是能够满足业务当前要求和不远的未来的发展要求的；
  3. 好的系统架构应该是能够节约成本（时间、金钱、人力），和提升效率（团队工作效率、系统开发和上限效率、系统运行效率），以及保证质量，这点非常重要；
  4. 好的系统架构应该是根据需要有所侧重的，因为不可能好处全占：有时候是用金钱换时间；有时候是牺牲运行效率提升开发效率；有时候是牺牲时间换取质量。每个阶段侧重点都可能不一样；
  5. 好的系统架构能够支持团队的扩展性和系统处理能力的扩展性，比如支持1万开发人员而不会混乱，支持亿级流量而不会引起性能瓶颈。

微服务的概念提出

微服务（Microservices）在2012年慢慢被提出，几位大师对其做了若干阐述和定义（Martin Fowler竟然不是第一个提出微服务架构概念的？-阿里云开发者社区 (aliyun.com)）。学习和理解微服务，首先要回答一个问题：微服务与早已存在的SOA（Service Oriented Architecture）有什么关系？

三位大师是这么阐述微服务这个概念的。

“Microservices - the new architectural style.” – Martin Fowler “Micro (u)Services Architecture -small, short lived services rather than SOA.” – Fred George “Loosely coupled service oriented architecture with bounded contexts.” – Adrain Cockcroft

松耦合 和DevOps紧密关联

微服务的实现

采用微服务的架构能够在一般情况下帮助设计出一个弹性的、可伸缩的、可演化的、可扩展的、可拆分的、可让更多团队平稳协作的系统架构。一般情况下，这样的系统架构就是我们需要的“好”的系统架构。

目前微服务的技术实现框架

主流的有两类：一类是以Java技术为主的Spring Cloud套件；另一类是跨语言的以Kubernetes容器化集群平台为核心的service mesh。

Spring Cloud

套件

Spring cloud

相关组件

ZooKeeper Eureka Zuul Hystrix Feign

Service mesh

Service mesh 是比较新的一代微服务的实践，其优点是方便跨语言和技术栈。

Istio

边车模式以及变种

系统的组成

计算模块

存储模块

通信模块

计算 存储 通信