什么是微服务架构？

之所以想讲这个微服务架构，是因为自己在工作的经历过程中有遇到过一个使用了6年的庞大系统，最后被重构成微服务架构的经历。

如果你有幸去面试一些互联网公司，或许你会遇到面试官问你微服务架构的知识。如果你不知道什么是微服务架构，和为什么需要它，那么这篇很适合小白的你，读一读。

01 没有微服务架构前

当时负责维护的是一个比较大的平台网站，最初这个平台选择的技术栈是yaf框架+mysql+前端。当时搭建开发的这个平台并没有前后端分离的思想。所以使用的是MVC的那一套，后端前端都写在一起。

业务在不多的情况下，使用MVC并没有什么大问题，核心的压力都是在后端需要对接前端功能。随着这个系统的功能不断完善和业务拓展微端服务器，这个系统的代码变得不断庞大。而原本的单平台内又诞生出了ERP系统，PC端和移动端。全部的代码都集成在了这一个yaf框架内。整个网站平台的全部源码都在这一份源码里了。

看似这个平台只要把不同的后台模块分布在不同的服务器上访问，共同调用一个核心的数据库可以运行就万事大吉了。

但是由于这个代码的平台从最初的搭建到后面的不断子系统开发微端服务器，由于技术团队人员轮换，这份源码经手的开发人员换了一批又一批。不同的技术leader要求的规范也变得不一样，要求的编码规范也不一致。由于前端的源码也是在这个框架内。对于后端开发人员编写的前端对接功能上，可能并没有前端开发人员那么规范。整份代码变得冗肿，代码不够规范，开发人员开发效率低下，在它的基础上扩展业务和功能已经变得麻烦。而网站的性能瓶颈也开始遇到问题，这时就想到要对这整个系统进行重构，对不同的模块进行拆分。

3、特性三：“去中心化”的治理技术

每个微服务允许使用不同的技术来开发， 且数据可以不再单独的保存在一个数据库中，允许多种数据库技术。

正是因为微服务架构拥有这些特点才慢慢的被越来越多的互联网公司所选择。

但是这也并不是一本万利的好事，我们也来看看微服务架构所带来的缺点。

04 它的缺点

前面说到微服务也有一些坑，那么都有什么坑呢？我们把所涉及到的开发人员都放到一起说一说。

所以在选择微服务架构时，也要看好利弊综合考虑再选择该架构。当然这也是架构师们所要考虑的事情了。但是如果你能够站在架构师的角度去思考问题，你会在思考中不断地进步。