微服务架构设计代表了一种架构设计思想。 使用当前的容器技术（例如Docker），可以在软件开发过程，部署和服务维护等各个方面提高效率。

  但是，并非所有业务场景都适用于微服务。 有时在非常简单的业务场景中，微服务会降低效率。 本文将讨论什么是微服务，其特性，好处和陷阱。

  1.什么是微服务

  微服务是一种软件架构样式。 它基于专注于单一职责和功能的小型功能块。 它使用模块化方法来组装复杂的大型应用程序。 每个功能块都使用独立于语言的API。  （例如REST）设置为可以相互通信，并且每个服务可以单独部署，它具有以下三个核心特征：

  微服务诞生于大型系统。 随着业务的快速增长，系统流量压力和复杂性将会增加。 系统的可维护性和可伸缩性已成为体系结构设计的主要考虑因素。 微服务体系结构设计概念是通过小型和美观的业务划分的。 独立自主实现优雅的设计和复杂系统的实现。

  微服务架构是面向结果的。 微服务架构设计风格的出现不是基于学术或标准设计，而是在软件架构设计领域的不断发展过程中，面对实际行业中遇到的问题，并出现解决实际问题的架构设计风格 。

  专注于服务设计的可替代性。 微服务架构设计风格要解决的核心问题之一是如何在大型系统中方便地维护和更换系统组件，而又不影响整个系统的稳定性。

  

  2.微服务的特点

  

每个微服务仅负责一个业务，并负责该业务的容量；

  每个微服务都可以独立部署，也就是说，无需依赖其他微服务和相关资源，例如数据库，内存缓存系统等。

  轻量级通信协议，例如REST，STOMP，AMQP等；

  服务的可替代性意味着原则上每个微服务都可以用不同的语言和框架来实现，并且替换已实现的微服务不会影响整个业务系统;

  每个微服务都有一个单独的数据存储；

  每个微服务都由一个小团队维护。 在按业务划分服务之后，每个微服务的维护将由一个由少量人员组成的小组组成；

 

  3.微服务的好处

  独立的可伸缩性，每个微服务可以水平或垂直独立地缩放，并可以根据业务的实际增长迅速扩展；

  具有独立的可升级性，每个微服务可以在不依赖其他服务的情况下独立升级和更新，结合用于持续发布的持续集成工具，开发人员可以独立快速地完成服务升级发布过程；

  易于维护，每个微服务的代码仅专注于完成单个业务类别的工作，因此微服务项目代码的数量将减少到IDE可以快速加载的大小，从而可以提高代码的可读性 ，从而提高研发人员的生产效率；

  语言独立性，研发人员可以选择最熟悉的语言和框架来完成其微服务项目（当然，通常会根据每个公司的实际技术堆栈需求），因此在面对新技术或新框架的选择时 时间，微服务可以更好地快速响应。

  隔离故障和资源。 当系统中发生不良的资源操作行为（例如内存泄漏和未关闭的数据库连接）时，它将仅影响单个微服务。

  优化跨团队沟通。 如果您想充分实践微服务架构设计风格，则研发团队将不可避免地根据新原则进行划分，从以前的按技能和职能划分到按业务划分（单个微服务）。 在这样的团队中，将有具有不同方向技能的研发人员，沟通效率要优于以前的组织结构除以技能；

  我们以“云”系统架构设计为基础，基于微服务架构设计风格，我们可以构建一个“云”友好系统，该系统可以轻松地与通用容器工具（例如Docker）结合使用，以构建一个持续发布的系统 IaaS和PaaS平台使它可以轻松地部署在各种“云”上，例如公共云，私有云和混合云。

4.避免微服务的陷阱

  不要从微服务开始。 在项目开始时，它们通常很小，不需要非常完全的业务拆分。 如果您从“微服务”开始，那将感觉有点像大锤。 当然，您的选择如果项目很大，那么从“微服务”开始是一个不错的选择。

  不要自己管理基础架构。 微服务是指一堆数据库，消息系统，数据缓存系统等，它们会带来相应的运维管理成本（前提是这里没有好的自动化运维平台和工具），建议使用 IaaS和PaaS平台来部署和发布它们以与它们连接；

  没有DevOps，也没有微服务。 如果研发团队不具备DevOps概念并实现它，而只想单独实现微服务，则实现过程将发现它比以前的体系结构维护更加困难。 主要原因是微服务需要继续。 工具或系统的协作（例如集成，连续部署和监视）可以减少其带来的维护成本；

  不要创建太多微服务。 微服务的业务粒度必须根据业务系统的实际状况和未来计划制定。 切记不要形成太细的分割粒度；

  由于服务被拆分并部署到不同的平台或网络，可能出现的延迟问题可能导致微服务之间的呼叫延迟，而服务之间的呼叫延迟可能导致整个系统响应缓慢；

  微服务不是灵丹妙药。