01-微服务架构简概

1. 问题描述

当我们使用ssm开发时我们使用maven的聚合工程，做到了模块的划分，但是使用SpringBoot工程之后，我们会发现所有代码又写到了一起，在一个工程中，很显然工程很庞大,拆分的思想好像没有了

SSM项目

SpringBoot项目

2. 单体架构

单体架构：通常来说，一个jar包或者一个war包中包含整个应用的所有的功能，这种架构我们称为单体架构

2.1. 单体架构图

2.2. 单体架构的优点

优点一：开发简单

优点二：部署简单

优点三：维护简单

优点四：成本低总结：适合小型创业型公司，或者一个公司产品的最初产品，后续重构，这样的公司用户量少，一个单体架构的项目就足以支持公司的所有业务功能。

2.3. 单体架构的问题

– 用户量越来越多，网站的访问量越来越大，导致后台服务器的负载越来越高

– 用户量大了需求多了，产品需求要满足不同的用户，会导致业务场景越来越复杂

– 随着业务的增加，jar包或者war包的体积越来越大，甚至达到几百兆或者上G，部署很痛苦

2.4. 单体架构优化的方式

– 横向增加服务器，让单台服务器变成多台机器的集群
– 垂直把业务功能模块拆分降低业务的耦合度，降低单个war包或者jar包带来对的伸缩性的问题
– 如果只是业务拆分，但是访问的数据也是同一个数据库的话数据库的压力也很大，所以数据库也要垂直切分

3. 微服务架构

微服务就是单体架构优化的一种解决方案，把不同的功能模块，业务逻辑可能拆分10个服务甚至100个服务，由于服务的变多，就导致项目的构建，发布，运维的复杂度会成倍增加，但是微服务会把我们复杂的业务逻辑拆分的简单化。降低了业务之间的耦合度。

3.1.微服务架构的优点

1：复杂度可控
       由于微服务是对业务的拆分，一个服务只需要关注一个特定的业务逻辑即可，体积小，复杂度低开发简单

   2：技术选型灵活
       由于每一个微服务都是一个团队或者个人开发或者维护，对于技术的选型你可以选择你擅长的

   3：扩展性强
       如果在以后的开发维护中，需要添加业务逻辑，只需要添加对应功能的微服务即可，不需要对其他微服务进行大的需改，并且如果某一个微服务的并发高时，可以针对这一个微服务做集群配置。

   4：独立部署
       每一个微服务都是一个独立的进程，独立发布，当这个微服务代码变更时只需要重新编译这个微服务部署即可其他的微服务可以不用动

   5：可以有自己的数据库
       每一个微服务都可以有自己模块的数据库，此时也可以体现了数据库拆分的思想缓解数据库的压力

   6：容错性
       在微服务架构中如果某一个服务出现了故障，我们可以使用让故障隔离在某一个服务中，其他服务可以通过重试，服务降级机制来完成整个项目的正常运行从而实现应用层面上的容错

3.2. 微服务架构的挑战

1：故障排查
        一次请求可能会经历不同的微服务，交互的链路可能非常长，并且每一个微服务都有自己的日志寻找问题源比较困难，需要逐层排查

2：服务监控
        如果是传统式项目真个业务逻辑都在一个包中，监控起来相对简单，但是微服务架构，可能存在几十上百个微服务对每一个微服务的监控以及链路交互的监控就很复杂

3：分布式的复杂性
        在微服务之间的远程调用情况下，多个微服务之间的调用需要通过远程调用，任何一个环节出现网络问题,延时问题会导致页面死在那个地方用户体验不要从而增加了应用的复杂性

4：服务依赖
        由于多个服务之间是有远程调用关系的，所以你复杂开发维护的服务每一次修改，都要考虑会不会对其他的服务造成影响等

5：运维成本
        微服务多，快速部署，可通过管理，快速扩容，这些都是运维人员面临的巨大的挑战