微服务概述

微服务并不是一门技术，而是一种架构风格。你可以使用任何一门开发语言、任务一种框架来实现一个微服务。微服务容易开发、理解和维护，可以独立部署、独立伸缩，非常灵活。

通过将单体应用分解成微服务，解决了复杂性问题。每个微服务负责处理单一的任务，微服务之间通过定义好的接口相互通信，最后组成一个庞大的微服务生态系统。

• 微服务的开发、构建和部署
  

每个微服务就是一个独立运行的应用，分别由专门的团队负责开发，开发人员可以自由选择他们熟悉的技术，也可以采用最新的技术，而且可以快速做出变更。所以对于开发人员来说，微服务给他们带来了极大的自由度，同时极大地提升了开发速度。

每个微服务可以独立开发、独立部署，而不像单体应用那样牵一发而动全身。每个微服务可以独立演化，在快速做出变更后进行部署，如果有必要，每天可以进行多次部署，因为微服务体积小，所以构建时间短，部署起来也非常方便。

• 微服务性能的扩展
  

每个微服务都可以独立伸缩，可以根据具体情况为每个微服务部署不同数量的实例，也可以为不同的微服务选择不同的硬件。比如，对于不是很关键的微服务可以使用便宜的硬件，对于负载不是很高的微服务就可以少部署几个实例。而对于高负载的关键微服务则多部署一些实例，并使用更好的硬件。

• 微服务的应用条件
  

采用微服务架构的门槛其实是很高的。Martin Fowler 认为，一个公司要采用微服务，必须满足三个基本前提条件，即快速配置能力、基本的监控能力和快速部署能力。而除此之外，要成功实施微服务，还有其它很多重要的因素需要考虑。

对于微服务的实践，我的理解是小公司一般没有符合要求的基础设施来运行微服务，哪怕是很小规模的微服务。好的微服务架构需要稳定的基础设施，这样的基础设施一般都很复杂，需要专门的团队来负责运维。只有在面临伸缩性挑战并决定要转向微服务架构的公司才会为组建这些团队所要耗费的成本买单，一般的小公司没有足够的能力来维护这样的一个微服务生态系统。

在公司发展的早期阶段，很难对系统的关键性功能进行组件化，因为新公司的应用一般不会有太多功能特性，也没有太多的功能需要被拆分成微服务。

所以，微服务的出现是行业发展到一定阶段的必然产物。而微服务在公司中的实施和应用，也是公司发展到一定规模的产物。

转自：

《生产微服务》
[美] Susan，J.，Fowler（苏珊，J.，福勒） 著；薛命灯 译