我对微服务架构的一些看法和理解

最近去面试几家公司，都被问到微服务的问题，可见微服务在企业应用中是多么流行。无论是大企业还是小企业的面试官，好像都把微服务作为衡量Java培训讲师水平的标准。虽然之前对微服务架构也有一定的了解，但是面试的时候总是不能够把微服务架构很好的回答出来。基于这个原因，所以才想把微服务架构总结一下。

一、传统架构

传统项目架构使用单体架构，就是一个项目集成了所有的功能模块。例如：一个商城的后台管理系统，可能包含用户管理、商品管理、订单管理等模块。如下图所示：

发布项目的时候，需要先把项目整体进行打包，然后再把打包后的文件发布到服务器上面。这样的缺点非常明显，比如说：
（1）项目的复杂度高
一个大型项目里面可能包含许多功能模块，而且模块之间肯定会存在一定的依赖关系，项目的复杂度非常高。如果其中某个模块出现问题，就有可能导致整个项目运行失败。

（2）部署时间长，影响范围大
由于大型项目的复杂度高，项目的构件和部署的时间也会随之增加。而且，如果某一个功能模块出现问题，那么解决问题后需要重新把整个项目重新发布。在发布过程中项目的所有功能都无法使用。

（3）功能扩展能力有限
单体架构的项目无法结合业务模块特点进行功能扩展，只能作为一个整体进行扩展，程序的伸缩性较差。

二、微服务架构

与传统架构方式不同，微服务架构把一个大型项目按照不同的功能拆分为不同的子模块。发布项目的时候，可以对各个子模块进行单独发布。每一个子模块都是运行在自己的进程中。模块之间通过一些通信机制进行数据通信。例如上面的商城后台系统，如果按照微服务架构来设计，每一个业务功能模块都可以作为一个子项目单独发布。如下图所示：

从上图可以看出，用户管理系统、商品管理系统、订单系统之间都是互相独立的，每一个系统都是运行在自己的进程中。它们可以通过一些轻量级的通信机制（如REST API）进行数据通信。

微服务架构相对于传统架构的优势：
（1）便于模块化开发
在一个大型项目里面，不同人员可能负责不同的模块。例如：张三负责用户管理模块，李四负责商品管理模块，王五负责订单管理模块。使用微服务架构把不同模块放在不同的子项目中，可以减少由于代码质量问题对整个项目的影响。

（2）部署应用的效率更高，模块之间的影响较少
不同模块可以单独部署。例如把用户管理模块部署的服务器1，把商品管理模块部署的服务器2。由于单个模块的代码量较少，部署的时候服务启动速度会更快。而且即使某个模块发生改变，只需要重新发布该模块即可，不会影响其他模块的功能使用。

（3）不受所使用技术的限制
开发人员可以根据项目业务需要和团队成员能力的特点，对不同模块选择不同的技术来实现。

上面介绍了微服务架构优点。但是在实际使用中也存在一些缺陷。例如：
（1）使用成本高
微服务架构底层是基于分布式技术来实现，需要有更多服务器的硬件支持，从而导致硬件成本增加。

（2）对项目设计和开发人员的技术要求更高
对于一个分布式系统来说，系统容器、网络延迟、高并发、事务控制都对软件设计和开发人员带来新的挑战。

（3）不同子模块中可能会存在相同功能
有些功能由于没有达到分解为一个微服务的程度（比如一个日期的工具类），这时候需要在各个子模块中都需要定义相同功能，导致有些功能重复。

所以，对于项目经理或架构师来说，采用怎么样的架构应该根据项目实际业务需求来决定。对于传统的单体式架构而言，可能更适合于一些功能简单、单一的应用（比如论坛系统）。如果要开发一些功能复杂的应用（比如：商城、ERP等等），由于这些应用里面有非常多的模块，如果把所有模块都放在一个项目里面，项目的维护性和扩展性会比较差。因此，这时候就可以考虑使用微服务架构对其进行设计。

三、总结

下面列出上面两种架构的不同之处：

	传统架构	微服务架构
对设计人员要求	相对较低	比较高
项目部署	整个项目打包发布	每个模块打包后单独部署
故障影响范围	影响范围较大	影响范围较小
系统响应速度	响应速度快，吞吐量小	响应速度慢，吞吐量大
学习难度	难度较小	难度大
技术多样性	技术单一	方便整合不同技术
系统扩展性	较差	很好
开发成本	成本少	成本大