为什么要使用微服务？微服务架构的发展史，我们有没有必要在项目里去使用微服务架构

前言

作为一个奋斗在一线的程序员，肯定要实时拥抱变化，实时关注最新、最热的技术的发展。让自己能够一直适应最新的技术栈，不被行业或社会所淘汰。面对最近炒的如火如燎的分布式微服务技术，就一个态度：可以不用但是不能不会，只有不断学习新技术做好自己的技术储备，才能面对各种迎面而来的业务变化和市场变化。

背景

说起什么是微服务架构，不得不说的就是我们应用架构体系的发展史了。应用是可以独立运行的程序代码，提供相对完善的业务功能。目前来说我们的软件架构可以分为三种架构类型：业务架构、应用架构、技术架构。他们之间的关系是，业务架构决定应用架构，技术架构支撑应用架构。架构的发展史是从单体架构 -> 分布式架构 -> SOA架构 再到微服务架构。如图：

单体架构

单体架构可以理解为一个完整的应用程序，在Java层面来说就是一个包含了展示层、业务层、持久层，从Controller-> Service层再到Dao层，一个war文件包含所有代码，没有任何业务拆分（也就是 all to one）。开发完毕后就是一个超大型的项目，进行部署。

优点：

• 易于开发

  开发人员可以用一个开发工具一个窗口很短时间内就可以完成一个单体应用的开发

• 易于测试

  因为不需要依赖其他的接口，测试可以省却很多时间

• 易于部署

  只需要把项目部署到运行目录内即可

缺点：

• 灵活度差

  如果业务有任何修改就是牵一发而动全身，整个程序需要从上到下所有层去修改，测试时需要整个程序部署完才能看出效果，开发过程中可能需要等待其他开发人员开发完毕才能完成部署，降低了团队的灵活性

• 降低系统性能

  原本可以直接访问数据层而现在多了一层，即使只包含一个功能也需要在各个层上写代码。

• 系统启动慢

  一个进程包含了所有的业务逻辑，涉及的启动模块较多，导致系统启动的速度变慢

• 拓展性差

  增加新东西时不能针对一个点添加，要全局性的增加。牵一发而动全身

分布式架构

传统的分布式架构，简单来说就是原本的单体架构按照业务垂直划分成多个应用，每个应用单独来说都是单体架构。通过API互相调用组成一个完整的应用项目。

优点：

依赖解耦，理解清晰

缺点

进程间调用可靠性降低，实现技术复杂

如图：

SOA架构

SOA即面向服务，面向服务的架构是一种软件体系的架构。通过其应用程序的不同组件使用网络上的通信协议向其他服务提供服务或消费服务。所以也是一种分布式架构。简单来讲，SOA是不同业务建立不同的服务，服务之间的交互粗粒度可以通过服务接口分级，这样松散耦合提高服务的可重用性，也让业务逻辑变得可组合，并且每个服务可以根据使用情况做出合理的部署，从而让服务变得规范，高性能，高可用。

SOA架构中主要有两个角色：服务提供者、服务消费者 阿里的Dubbo是SOA架构体系的经典实现

优点

• 把模块拆分，使用接口通信，降低模块之间的耦合度
• 把项目拆分成不同的子项目，不同团队负责不同的子项目
• 增加功能时只需要增加一个子项目，调用其他系统的接口即可
• 可以灵活的进行分布式部署

缺点

• 系统之间的交互使用远程通信，增加接口开发量
• 部署，运维服务难度提升，业务及开发团队需要一定规模

微服务架构

微服务架构某种程度上就是SOA架构的升级版，微服务的概念最早源于Martin Fowler的《Microservices》。总体来说，微服务是一种架构风格。对于一个大型复杂的业务系统，它的业务功能可以拆分成多个相互独立的微服务，各个微服务之间是松耦合的，通过各种远程协议进行同步/异步通信。各微服务可以被独立部署、拓/缩容以及升/降级。

优点

• 把模块拆分，使用接口通信，降低模块之间的耦合度
• 把项目拆分成不同的子项目，不同团队负责不同的子项目
• 增加功能时只需要增加一个服务，调用其他服务即可
• 部署可以按需部署，更灵活的管理服务部署、拓/缩容以及升/降级。

缺点

• 各个不同的服务接口提供，开发量增加
• 需要明确的业务职责划分，分库分表，技术实现复杂

总结

微服务确实为互联网的发展带来了很多的好处和方便，但是我们在使用一些新技术时还是要理性的看待的，微服务架构的落地除了给我们带来技术上的领先以及业务上很多问题的解决和便利，

但是我们还是要先理性评估下自己的业务目前有没有必要开始使用微服务架构。自己的团队目前来说能不能支撑微服务技术给我们带来的一些麻烦：研发工作量增加、分布式锁、分布式事务、调用链路、日志、业务职责划分，分库分表，以及运维方面的部署，配置，服务监控