概述
从谷歌的搜索指数来看，微服务的热度在进入2017年后迅速上升，国内的各大会议和论坛也开始频繁讨论这一技术，各大一线互联网公司纷纷将其引入并在实际业务中应用。
然而，很多国内中小规模的技术团队对微服务的概念还不甚了解，不知道是否应该引入微服务。还有一些团队为了追求技术热点，盲目引入微服务，但由于缺乏相应的技术掌控能力，最终影响了业务的稳定性。
为了帮助中小规模团队更好地了解微服务，我结合自己在微博多年的业务实践，整理出了一套微服务落地经验，从基础理论到架构实践，再结合业界最新趋势分析，希望能帮助中小团队了解微服务的本质及其业务价值，从而做出正确的判断。
微服务的定义
根据维基百科的定义，微服务概念由Martin Fowler和James Lewis在2014年提出。他们将微服务定义为由单一应用程序构成的小服务，每个服务拥有自己的进程与轻量化处理，服务按照业务功能设计，以全自动方式部署，通过HTTP API进行通信。服务使用最小规模的集中管理（如Docker）技术，可以用不同的编程语言和数据库等。
单体应用
在讨论微服务之前，先介绍一下单体应用。早期的互联网公司应用技术栈主要分为LAMP（Linux + Apache + MySQL + PHP）和MVC（Spring + iBatis/Hibernate + Tomcat）两大流派。无论是LAMP还是MVC，都是为单体应用架构设计的，优点是学习成本低，开发上手快，测试、部署、运维也方便，甚至一个人可以完成一个网站的开发与部署。
然而，随着业务规模的扩大和团队开发人员的增加，单体应用架构开始出现问题，例如：
部署效率低：代码越来越多，依赖的资源越来越多，编译打包和部署测试一次可能需要10分钟以上。
团队协作开发成本高：人员较少时协作尚可，但一旦团队扩展，超过5人修改代码，合并后只要一处功能有问题，就需重新编译打包和测试，效率低下。
系统高可用性差：所有功能都部署在同一个WAR包中，某一功能代码有问题会影响整个应用。
线上发布变慢：代码膨胀导致服务启动时间变长，发布耗时久。
为了解决这些问题，服务化的思想应运而生。
服务化
服务化就是将传统的单机应用中的本地方法调用改造成通过RPC接口的远程方法调用。例如，将用户模块从单体应用中拆分出来，独立成一个服务，以RPC接口形式对外提供服务。这样，用户模块可以独立开发、测试、上线和运维，不与主模块耦合。
微服务
从2014年开始，得益于Docker等容器化技术的成熟以及DevOps文化的兴起，服务化思想进一步演化为微服务。
微服务与服务化的主要区别在于：
服务拆分粒度更细：微服务是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块无关，就可以拆分为一个微服务。
服务独立部署：每个微服务都独立打包部署，互不影响。
服务独立维护：每个微服务可以由一个小团队甚至个人开发、测试、发布和运维。
服务治理要求高：服务数量增加，需要有统一的服务治理平台进行管理。
总结
微服务架构将复杂臃肿的单体应用进行细粒度的服务化拆分，每个服务独立打包部署，交由小团队进行开发和运维，从而大大提高了应用交付效率，并被各大互联网公司广泛采用。