第四周

传统单体架构所有的业务逻辑都写在一起，部署在一台应用服务器上，随着用户增涨对应用服务器的资源要求也越来越高，在这个阶段我们通常采用的方式，将数据库，文件存储系统从我们的应用服务器分离出去，从而改善性能，当我们的访问量越来越大，这种架构下我们只能不断的增强应用服务器的配置来应对高并发，而硬件堆到极限，这种构架就无法承受更大的流量了。

从传统构架发发展到目前流行的微服务架构，发生了一个质变，就是从传统增加硬件的垂直扩展变成当下动态水平扩展来解决访问量的压力，这是一个思维层面的转变，同时产生了以从水平扩展来解决问题的技术方案。

业务服务的拆分

在微服务架构中，我们把业务进行领域拆分，使每个业务形成独立的闭环，服务与服务之间通过远程RPC去调用，比如服务与服务调用有feign和dubbo它们用不同的协议实现了服务之间的调用。而服务之间要调用，需要知道其它服务提供者，这就产生了Zookeeper 和 Nacos 这样的注册中心，服务需要先把自己注册到服务中心，然后通过注册中心找到对应的提供者，这样业务层就实现了水平扩展以及高可用，当某一业务有访问压力时就动态的进行扩展，硬件就不再成为束缚系统的唯一条件。随着业务的拆分，业务的部署运维越来越具有挑战性，于是有了doker与k8s等虚拟化技术。

数据库的瓶颈

解决了业务层的问题，数据库就成了我们系统最大的瓶颈，传统的方式是垂直拆分与水平拆分，这都可以使我的数据库进行水平扩展来应对访问压力，但同时使我们的业务操作变的复杂无比，如越库的查询，而这些问题在今天也都有很多优秀的工具来帮我们解决如Mycat等产品。

其次不同的场景我们可以用不同的解决方案，如聊天等大量高io操作的场景，我们可以使用NOSQL来存储数据。如果项目立项就是类淘宝这种大流量平台，则完全可以使用当下流行的分布式数据库来替代传统的MYSQL。

微服务带来的挑战

微服务不仅是技术框架上的转变，更是一种思维方式上的转变，这种技术方案，解决问题的同时也大大提高了开发门槛，同时也带来了新的问题。

如果服务与服务之间的调用存在事务，我们可用seata这种工具去解决问题，也可以用RabbitMQ异步调用的方式解决业务问题。当进行秒杀活动时我们可以用redis和MQ来削峰填谷。当支付流程过于复杂时我们可以用MQ来解耦...

总之解决的问题越多，产生的新问题也就越多，学习的难度也来越来越大，微服务的发展使我们开发人员更多的关注并解决一些非业务层面的问题，好像偏离了开发的本质，但我们的眼光不能局限于此，服务网格的落地，像是不但的暗示着我们，微服务终将成为过去，服务的注册发现、调用、熔断等，在未来都将下沉为基础设施，而我们的问题又将回到业务层面（个人见解）。