目前越来越多的话题都围绕着微服务，许多公司也在使用微服务架构。笔者也刚刚接触微服务不久，也算是微服务架构的初学者，谨以本文来记录学习过程中对微服务架构的一些理解。好啦，废话不多说，我们往下看。
微服务，英文名MicroService，他是一种架构风格一种架构设计模式，通常表现为一个庞大而复杂的应用其背后是由数个职责分明的服务组成，这些服务他们各自分工明确，可以独立部署同时也可以根据需求进行扩展，各个服务之间松耦合并且可相互通信。
结合我们生活来说，一个公司内部组织架构也算是一种微服务的表现，公司内部按不同职能划分了许多部门，人事部门、财务部门、开发部门、测试部门、运维部门等等这些部门都是一个个的微服务，各个部门之间相互独立办公同时也相互协同办公。这些所有的部门组成了公司的整体。
微服务的概念出自于马丁·福勒（Martin fowler），他对微服务的定义如下：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，对具体的服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建 。（摘自王磊先生的《微服务架构与实践》）
微服务从最初的无人问津，到现在大红大紫，被大家广泛使用。那么问题来了，为什么要用微服务架构？为什么就不用以前的架构了？我们先来了解一下传统的架构方式。
应用程序作为单体进行打包和部署，称之为单体应用，例如基于SpringMVC+Mybatis+Spring开发的许多Java项目最终被打包成一个war格式的文件部署在Tomcat或者Jetty服务器上。而这种单体应用的架构理论就称之为单体架构。
一个单体应用他可能内部也区分了业务逻辑模块，但最终都打包为一个单体，随着时间的推移，单体式应用的不足就暴露出来了。
微服务架构往往用于解决复杂问题，他适合将复杂庞大的问题拆分为相互独立又相互联系的小个体。相比于单体架构，微服务架构是构建业务复杂度高，规模大，需要长期持续迭代这一类应用时更好的选择。
现在已经有很多公司采用微服务架构来解决单体式架构可能会造成的隐患，笔者所在的团队就选用了基于SpringBoot的SpringCloud，如此一来能够大大提高开发效率的同时降低项目的维护难度，将项目分解为多个微服务组件，各个相对独立的同时又相互协作。不用再构建并且维护一个臃肿又令人头疼的单体应用。
说了那么多，那在使用微服务之后到底有哪些优势呢？
任何架构都是在实际开发中慢慢演化出来的，是为更好地适应开发者们的需求。所以微服务也存在着自身的不足之处。
没有哪一个好的架构是被设计出来的，也没有哪一个架构可以解决所有的问题，每一个好的架构都是在不断适应业务需求的过程中不断被演化出来的。所以每种架构方式都有各自的优势和缺陷，没有最好，只有最合适！
如何通俗易懂的解释微服务：http://www.cnblogs.com/hang520/p/9239071.html
微服务从涉及到部署：https://github.com/DocsHome/microservices
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。