为什么需要微服务架构？
单体架构只适合用户群体较少的场景，当我们的业务量越来越大，单体架构已经无法满足我们的需求，通过拆分单体架构项目变成分布式架构才能应对大规模的应用场景。
单体架构图
微服务架构
如何拆分单体架构呢？下面有两种方式对项目进行拆分：
- 垂直拆分：按照业务模块进行拆分，比如电商系统（用户服务，商品服务，订单服务，支付服务）
- 水平拆分：按照数据量进行拆分，比如电商系统数据库中的数据按照用户ID划分，从1-1000拆分；按照时间划分，3个月前的订单，最近三个月的订单；按地区划分，北京，天津，上海的订单。
为什么要这样做呢？因为单点故障(系统一处发生故障，导致整个系统崩溃)对系统造成的影响，防止高并发造成数据雪崩，影响用户正常使用。
除了业务之间做了隔离，还要考虑数据库之间的隔离，一个业务用一套自己的数据库。不读取对方的数据库，只通过服务进行耦合。
架构是怎么样变化的过程？
SOA（基于服务的架构）和单体架构没什么两样，图中的齿轮就是一个一个的服务，调用一个服务就会带动另一个服务，整个服务架构高度耦合。
微服务架构松耦合，每一个微服务独立完整运行，开发速度快，部署快，隔离性高，扩展度好。但是测试和维护比较麻烦，需要用SpringCloud部署和调度。
性能
构建分布式系统目的是为了提升项目访问的吞吐量，提高系统可用性。从技术层面对进行相应的优化，主要在两个方面，大流量处理把大数量的请求用集群的方式分散到不同的机器上。对业务的可用性要防止发生雪崩，我们要对服务进行降级处理。
提高性能这块还有一些方法：
- 加缓存：以前做单体架构的时候把数据一股脑的放在redis中，现在面对的分布式架构，再用以前的方式做的话，如果reids挂了，那么大量的请求都跑到mysql里，造成不可挽回的后果。redis集群很好的解决这个问题，一个redis不够用，那我就多加几台redis，把它们变成一个个节点，串起来统一管理。
- 负载均衡：把请求分开到不同的机器上，避免某个机器压力过大
- 异步：如果在同一时刻突然爆发式的发起请求，很容易导致系统压力过大。消息队列让所有请求都排好队，根据后端能够处理的速度来处理请求。速度会变慢，队列中的消息会丢失，要对消息做持久化。
- 数据镜像：把数据拷贝多份，修改一个节点上的数据，会自动同步数据。
- 数据分区：这个有点复杂，涉及到不同位置访问不同数据区
docker可以方便的解决上所遇到的问题，虚拟容器化的技术可以很方便的软件部署、调度、管理。
监控
监控服务情况：服务搭建好之后，我们想了解系统内部资源调度和外部API服务使用情况，可以用Zipkin开源框架。
这张图上表示的服务调度时间，有了这些直观的数据表示，我们可以快速了解用户访问了哪些请求出现问题，帮助我们快速排查。
如何操作调度处理？
- 如果发现某个服务过慢因为cpu使用过多，我们可以做弹性伸缩。意思就是根据需求动态调整系统资源（实例，内存，网络），在负载较轻的情况，自动减少系统资源；在负载较重的情况，自动增加系统资源。达到资源的高效使用和成本优化。
- 如果出现mysql处理过慢，通过流量限制或者降级处理。
