微服务架构有用么?

     很久很久之前我听说了SOA，我不知道这是干嘛的；很久之前我听说了微服务架构，我又不知道这是干嘛的。我就一直在问我自己现在的项目架构很落伍么，我怎么感觉它还是能满足我的需求的呢；新的架构能解决我的什么痛点，他们提到的现有的架构的缺点我没有感觉到，他们提到的新框架的优点我也不以为然。想了好久之后，我突然明悟：我的项目不适合这个架构。

     先说结论：微服务结构为大型项目（几十个人、几十万行代码）或多技术架构而生

     微服务架构： 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建 （ 马丁 -福勒）

         优点：1）易于维护：拆分成小的服务之后，业务变得纯粹，新功能开发、缺陷定位修复较简单。

     2）缩短交付周期短：不会因其他的业务或需求而影响本服务的交付。

     3）新人培养周期短：新人来后，第一时间了解和参与项目是很重要的，而一个较小的服务则在代码或业务逻辑上都易于理解和部署。

     4）技术选型灵活：我们现有的一种主流语言可以解决绝大部分的需求，但是并不是百分百；现在日益涌现的新技术也证明了他们的价值，在一个旧有项目上应用新技术，应用的大小就成了关键所在。

    微服务结构的优点都来自于服务的拆分，那么另一方面，拆分的缺点也是微服务的缺点：

     缺点：1）运营麻烦：体验过维护很多个项目的人都了解部署很多个应用的麻烦

     2）基础共用性：项目的简单与否在于是否有扎实的基础。分成很多个应用之后，基础的共用便是一个很大的问题。

     3）拆分依据：即使满足上面的条件，拆分仍然是一个很大的难点，只懂理论是无法解决现实中遇到的各种各样的拆分问题的。不合理的拆分会让上面的优点都变成缺点。

     为什么我的项目不适合微服务结构：

     1）技术单一：我的项目属于偏业务型系统，技术比较单一（正在积极采用新的、更合适的技术）

     2）项目较小：一个业务线项目的日常维护和开发人员不到五个，可想项目有多简单

     

所以，对于我这种简单的项目，微服务架构是没有什么用武之地的。

     所以，再说一遍，微服务结构有用，但是是为大型项目（几十个人、几十万行代码）或多技术架构而生

参考： http://www.infoq.com/cn/articles/analysis-the-architecture-of-microservice-part-01?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk