微服务的概念出现不是一天两天了，但是要追溯它的源头还要看SOA，毕竟微服务只是一种比较现代化的细粒度的SOA实现方式，并非从天而降突然出现的。但不得不承认，IT架构实现了从all in one到微服务架构转变，微服务架构模式（Microservice Architect Pattern）开始被越来越多的企业所接受。

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

如何避免盲人摸象

比如某大型互联网公司的技术主管就深感微服务架构优势多多，比如复杂可控、灵活可扩展、独立部署、开发展对性强等等，当然最重要的还有降低TCO，毕竟在微服务架构模式下，当某一组件发生故障时，不会发现单块架构系统的进程内扩散等弊端，故障会被隔离在单个服务中。

看起来好处多多，但是该部门程序员却表达了不满。因为在他们看来自己做了很多无用功。而且无论是分区的数据库架构还是对微服务架构的测试都有着极大的挑战。Nginx认为：“微服务”强调了服务大小，实际上，有一些开发者鼓吹建立稍微大一些的，10-100 LOC服务组。尽管小服务更乐于被采用，但是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用，实现敏捷开发和部署。

ohn Allspaw与Adrian Cockcroft争论微服务

由此可见，针对微服务这一热门话题，并没有绝对的好坏之分。笔者认为，企业在选择IT架构模式时应该根据自身需求来平衡，如果只需要建构一个简单的应用，那大可不必用微服务架构，单体式的架构可能更适合你；如果企业需要建构复杂应用，微服务架构化整为零的功能还是值得肯定的，但是在应用过程中微服务也有自身缺点，需要警惕。

本文转自d1net（转载）