单体应用和微服务

我们先来看一下，我们以前单体应用开发的结构。单体应用通常是采用三层架构的架构模式构建的。

表现层通常是由html，jsp，thymeleaf等模版引擎做为视图，控制器通常用servlet或MVC框架（springMVC、struts等）控制流程的走向。

再由spring通过IOC和AOP提供服务的支持，以及spring组件的管理。从而在业务层中实现事务管理。

持久层通常是由JDBC或ORM持久框架（Mybatis、Hibernate等）进行数据库数据和对象数据的交互和相互转换。

最后，再将整个WEB应用程序打包成war包，然后布署到tomcat中。通过tomcat提供的WEB容器的支持，用户就可以访问tomcat，从而得到WEB应用程序中相关的服务。

单体应用架构的优缺点

优点

便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享。

易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始。

易于部署：只需将单个归档文件复制到单个目录下。

 缺点

复杂性高：由于是单个归档文件，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。

技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。

扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。

阻碍技术创新：对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。

另外，在单体应用中，如果某一个模块发生异常或内存溢出，可能会导致整个WEB应用程序崩溃。

综上所述，采用单体应用开发互联网开发项目的风险是很高的。所以，出现了SOA来优化单体应用。

 

什么是SOA呢？

SOA是面向服务的架构，比如，现在有一个WEB应用程序，需要提供销售、统计、进货、库存管理等功能。按照SOA的理念中，可以将WEB应用程序进行面向服务的切分。将销售、统计、进货、库存管理等功能分别进行开发和布署。

这样的好处是，如果其中一个模块出现异常或内存溢出，只影响当前模块，其他的模块还可以正常工作，正常提供服务。而且不同的模块可以采用不同的语言进行开发。

SOA架构又带一个新的问题，通过面向服务的切分后，各个服务之间很可能存在一些依赖关系。随着业务复杂度的增加，可能导致各个服务器之间的关系非常混乱。如何处理这个问题呢？

我们可以将每个服务的模块加入ESB企业服务总线，ESB提供了连接企业内部及跨企业间新的和现有软件应用程序的功能，以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中，ESB用于组件层以及服务层之间，它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。

如果销售模块要调用库存管理模块，那么可以通过访问ESB中的WEBService，通过SOAP简单对象访问协议，完成和库存管理模块之间的数据交互，这样整个应用就比较协调了。

微服务架构

微服务是一种架构风格，即将单体应用划分为小型的服务单元，微服务之间使用 HTTP 的 API 进行资源访问与操作。这一点和SOA很类似。

微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以独立对外提供服务。微服务不再强调传统SOA架构里面比较重的ESB企业服务总线。微服务强调每个微服务都有自己独立的运行空间，包括数据库资源。微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。相比SOA而言，微服务的切分粒度会更小。

所以，微服务架构是 SOA 架构思想的一种扩展，更加强调服务个体的独立性、拆分粒度更小。


微服务架构的优势

使用微服务架构能够为我们带来如下好处：

1）服务的独立部署
每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。

2）服务的快速启动
拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了。

3）更加适合敏捷开发
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。

4）职责专一，由专门的团队负责专门的服务
业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。

5）服务可以动态按需扩容
当某个服务的访问量较大时，我们只需要将这个服务扩容即可。

6）代码的复用
每个服务都提供 REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。

微服务架构的劣势

微服务其实是一把双刃剑，既然有利必然也会有弊。下面我们来谈谈微服务有哪些弊端，以及能采取什么办法避免。

1）分布式部署，调用的复杂性高
单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都是独立部署的，通过 HTTP 来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。

2）独立的数据库，分布式事务的挑战
每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务，可以选择适合自身业务的数据，比如订单服务可以用 MySQL、评论服务可以用 Mongodb、商品搜索服务可以用 Elasticsearch。缺点就是事务的问题了，在不同的服务之间如何实现事务的控制。

3）测试的难度提升
服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的。测试一个服务时，可能会对其他服务有依赖，这样增测试的难度。

4）运维难度的提升
在采用传统的单体应用时，我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了，但这在微服务架构下是行不通的。当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了。