微服务（Microservice）那点事儿

微服务的兴起

在单体式架构时代，系统里就只有一套代码，一个应用服务了所有的请求。2005年的云计算大会上，Dr. Peter Rogers第一次提出了micro web services的概念，而微服务的崛起，是等到了2011年。互联网时代的崛起，面对指数性增加的请求和横向扩容、快速变更上线等需要，单体式架构无疑无法很好地去服务，而微服务架构开始成为了业界的专注对象。当时最早实验微服务架构的公司，就包括了大型网络公司Netflix和Amazon。

一个微服务架构的系统是一个分布式系统，系统内会由若干个应用组成，每个应用就是一个微服务。根据需求，每个微服务应用可以部署一定数量的服务器，也可以支持横向扩展，随时支持流量的变化。

微服务架构定义

单体式架构中一个个的功能/业务领域都可以成为微服务架构中单一的微服务，而各个微服务可以根据需求横向扩容，不再是单一的1:1的比例。微服务架构中通常会有个统一网关对外提供服务，对内调用都通过底层网络进行，服务之间都有着上下游的关系，随着系统的成长，微服务之间的关系往往会越发复杂。每个微服务都是自己的一套代码，彼此对技术栈没有强一致的需求。

微服务解决了什么问题

微服务带来了哪些挑战

微服务拆分策略

微服务需要的基础设施

微服务并不是很多人认为的那样又简单又轻量级。要做好微服务，上图中罗列的基础设施都是必不可少的，否则微服务就会变成一个焦油坑，让业务和团队在里面不断挣扎且无法自拔。因此也可以说，微服务并没有减少复杂度，而只是将复杂度从 ESB 转移到了基础设施。可以看到，“服务发现”“服务路由”等其实都是 ESB 的功能，只是在微服务中剥离出来成了独立的基础系统。

虽然建设完善的微服务基础设施是一项庞大的工程，但也不用太过灰心，认为自己团队小或者公司规模不大就不能实施微服务了。第一个原因是已经有开源的微服务基础设施全家桶了，例如大名鼎鼎的Spring Cloud 项目，涵盖了服务发现、服务路由、网关、配置中心等功能；第二个原因是如果微服务的数量并不是很多的话，并不是每个基础设施都是必须的。

通常情况下，建议按照下面优先级来搭建基础设施：

1. 服务发现、服务路由、服务容错：这是最基本的微服务基础设施
2. 接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率
3. 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率
4. 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率

以上3和4这两类基础设施，其重要性会随着微服务节点数量增加而越来越重要，但在微服务节点数量较少的时候，可以通过人工的方式支撑，虽然效率不高，但也基本能够顶住。