在云原生概念一文中已经对微服务进行了简单的介绍，这里详细介绍下什么是微服务、微服务的特征有哪些，微服务的优点及缺点。
微服务定义
微服务没有统一的定义，业内主流的定义还是Martin Fowler和James Lewis在2014年发表的博客中对微服务的定义。关键描述如下：
The microservice architectural style is an approach to developing a single application as a suite of small services,
each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
微服务架构风格是一种将单一应用开发为一组小型服务的方法。在微服务架构中，每个微服务运行在自己的进程中，微服务间通信采用轻量级通信机制(通常使用HTTP资源API)。这些服务围绕业务能力构建，并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
微服务是从单体应用演化而来，目的是解决单体应用过度复杂，难以开发、运维，更难以实现商业成功等问题。每个微服务都是独立的进程，可以使用不同的技术栈实现，微服务间使用轻量级的进程间通信机制。从单体服务到微服务，其难点在于如何将单一应用拆分成多个服务，不同的划分标准，带来不同的效能(避免开发之间职责不清晰、运维难度过大)。此外，当规模化微服务后，还需依赖不可变基础设施和自动化运维来减少开发人员的压力，降本增效。
微服务特征
微服务架构是一种分布式架构，但微服务架构也有自身特征，具体来说，可以分为如下九大特征：(1) Componentization via Services(服务组件化)、(2) Organized around Business Capabilities(围绕业务能力组织)、(3) Products not Projects(是产品，而不是项目)、(4) Smart endpoints and dumb pipes(智能端点和哑巴管道)、(5) Decentralized Governance(去中心化治理)、(6) Decentralized Data Management(去中心化数据管理)、(7) Infrastructure Automation(基础设施自动化)、(8) Design for failure(为失效设计)、(9) Evolutionary Design(进化式设计)。
(1) Componentization via Services(服务组件化)
在软件开发领域，通过搭积木的方式构建应用一直是软件开发人员的目标，微服务架构则尝试将服务组件化。这里的组件是一个可独立替换和独立升级的软件单元。使用服务作为组件有以下优势：(a)服务是可独立部署的；(b)更加明确的组件接口：服务通过明确的远程调用机制可以避免组件间的紧耦合。但使用服务作为组件也会引入一些缺点，如：(a)远程调用比进程内调用更昂贵；(b)会使远程API设计成粗粒度，不便于使用(为了屏蔽一些对用户透明的内部实现细节)。
(2) Organized around Business Capabilities(围绕业务能力组织)
在将单体应用拆分时，如果按技术层面拆分，则会拆分诸如：UI团队、后端团队、数据库团队等，但是这种组织拆分会带来一个问题：即使一个很小问题的修改，也可能需要涉及多个团队的协作。微服务架构倡导各服务自治，所以这样的团队划分，不利于微服务架构的落地。在组织架构和系统设计之间存在一个定律——康威定律，即任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。所以，在落地微服务架构前，应先构建相应的组织架构。微服务架构提倡通过业务来拆分/划分应用，同样地，也应按照业务来组织架构。按照这种指导原则，每个微服务团队都会承载一部分业务，且有独立的UI人员、后端人员、数据库人员。为了体现技术和产品的差异性，这个团队会有独立的技术负责人和产品负责人，并以产品负责人作为整个团队的决策者。当然，为了管理多个微服务团队，仍需构建金字塔形组织结构以协同多个微服务团队，但是这是在微服务团队之上的组织结构。基于技术和业务拆分组织和系统的示例图如下：
(3) Products not Projects(是产品，而不是项目)
传统软件开发模式中，开发团队不需直面客户，只需将软件提供给运维，由运维和销售团队支撑产品，这种模式会导致开发人员和用户的隔离，不能及时的响应用户、适应市场变化。微服务架构认为一个团队应该负责产品的整个生命周期，这与Amazon 提倡“you build, you run it”理念一致。当然，微服务团队面向产品后，也需承担运维职责。
(4) Smart endpoints and dumb pipes(智能端点和哑巴管道)
智能端点，字面意思就是一个拥有智慧的端点。对于微服务架构来说，这里的端点就是一个个微服务。而所谓的智能，则是指具备独立与外部通信的能力。哑巴管道，字面意思就是一个不会说话的管道。对于微服务架构来说，这里的管道就是通信管道。而所谓的哑巴，则是指通信管道仅执行通信传递，不做额外的处理。这里的dump理解成stupid更合适。所以，基于微服务构建的应用会尽可能地解耦和内聚——端口拥有自己的领域逻辑，可接收请求，执行适当的逻辑并响应请求。微服务架构下推荐使用REST API的HTTP请求-响应或在轻量级消息总线上传递消息。把单体架构变成微服务架构，通信模式也需要改变。一种直接的转换是从内存方法调用转变成RPC，但这会导致频繁通信且性能不好。相反，微服务架构下需要使用粗粒度通信代替细粒度通信。
(5) Decentralized Governance(去中心化治理)
集中治理的一个后果是技术平台的单一标准化发展趋势。不是每个问题都是钉子，不是每个问题都是锤子。我们更喜欢使用正确的工具来完成工作。使用单一的技术栈，最大的坏处是面对变化时，无法快速的响应。当服务规模庞大时，对单一技术平台进行技术栈变更的代价是巨大的。去中心化治理的最高境界就是亚马逊广为流传的"you build it, you run it"理念：团队要对他们构建的软件的各方面负责，包括7*24小时的运营。
(6) Decentralized Data Management(去中心化数据管理)
基于业务拆分微服务时，不仅分离了业务，还分离了数据存储。微服务更倾向于让每个服务管理自己的数据库，或者同一数据库技术的不同实例，或完全不同的数据库系统。单体应用和微服务应用数据管理差异如下：
需要说明的是，使用微服务开发后，必然会引入分布式事务问题。后面会单独介绍分布式事务，这里不再展开介绍。
(7) Infrastructure Automation(基础设施自动化)
当微服务规模化后，对微服务的管理还应实现自动化，特别是基础设施的自动化。如容器的构建、服务实例的启动、监控、日志等等。基础设施自动化在软件开发层面示意图如下：
(8) Design for failure(为失效设计)
使用服务作为组件的一个后果：应用需要被设计成能够容忍服务失效。任何服务调用方都可能因为服务提供方不可用而失败，服务调用方必须尽可能优雅地应对这种失败。与单体应用设计相比这是微服务的劣势，因为它引入了额外的复杂度。为应对随时可能失败的服务，成熟的微服务应该能做到：
(1) 快速检测故障
(2) 自动恢复服务
(3) 应用程序的实时监控：包括性能指标(如TPS)和业务指标(如在线人数等)
(4) 告警系统：通知开发团队跟进和调查
(5) 日志系统：方便各服务定位问题
总结来说，对于微服务架构，应考虑容错性设计、并构建强大的可观测系统(监控、告警、日志)，否则这些职责将落到开发人员身上，降低开发人员的幸福指数。
(9) Evolutionary Design(进化式设计)
微服务划分的直接好处就是每个微服务可以独立更换或升级，只需保证向后兼容。微服务强调可替代性，通过变更模式来驱动模块化：同时变化的东西保持在同一模块中。系统中很少变更的部分应该和正在经历大量扰动的部分放在不同的服务里。服务的拆分与合并不是一成不变的，应随着对业务理解加深，合理的拆分或合并各微服务。
微服务优缺点
微服务架构从单体架构演变而来，解决了单体架构下应用复杂带来的开发、运维、市场等问题，但是事物总是具有两面性。微服务架构也需要容忍服务拆分后带来的一系列问题，如容错性设计、分布式事务等。接下来将简单梳理下服微服务的优缺点。
优点
微服务架构有如下好处：
(1) 使大型的复杂应用可以持续交付和持续部署。微服务架构最重要的好处是它可以实现大型的复杂应用的持续交付和持续部署。持续交付和持续部署时DevOps的一部分，DevOps是一套快速、频繁、可靠的软件交付实践。
(2) 服务自治性。一个微服务就是一个独立的实体。它可以独立的部署
(3) 技术异构性。微服务架构以进程为一等公民，而进程间支持使用通用的通信方式进行交流。这就意味着不同微服务间可以使用不同的技术栈实现。
(4) 独立扩展。单体应用只能作为一个整体进行扩展，即使系统中只有一小部分存在性能问题，也需要对整个服务进行扩展。微服务应用则进一步量化资源，不同的微服务根据自身需求选择扩容或缩容，从而实现资源的合理使用。
(5) 独立部署。在微服务架构中，每个服务可以独立部署，这样就能更快的对特定部分的代码进行部署。如紧急修复一个生产环境的问题或上线一个功能等。
(6) 可组合性。在微服务架构中，各微服务会开发接口供外部使用，当特定的业务需要基于这些接口组合成一个新业务时，也就实现了多服务的组合。
缺点
没有一项技术可以被称为"银弹"，微服务在解决单体应用复杂度的问题时，也引入新的问题。主要如下：
(1) 服务拆分和定义是一项挑战。采用微服务架构最大的问题就是没有一个具体的、标准的算法用来完成服务的拆分。而且服务的拆分或合并是一个持续的过程，直到服务消亡。
(2) 分布式系统的复杂性需要解决。微服务架构是分布式架构的一种实现，所以微服务架构天然具有分布式架构的复杂度。微服务间必须进行网络通信，而网络通信是不可靠的，微服务架构必须处理这种情况，以保证可用性。微服务架构还引入显著的运维复杂性。必须管理更多的活动组件：不同类型服务的多个实例。
(3) 多团队协作难度更大。使用微服务架构的另一个挑战在于当开发或部署跨越多个服务的功能时，需要谨慎地协调更多团队。也即实现协同开发。
参考
微服务设计 Sam Newman 著 崔力强 张骏 译
微服务架构设计模式 Chris Richardson 著 喻勇 译
https://www.martinfowler.com/articles/microservices.html Microservices definition
https://www.jianshu.com/p/df87c6b4d3b7 Martin Fowler的《Microservices-微服务》
https://queue.acm.org/detail.cfm?id=1142065 Learning from the Amazon technology platform
https://nordicapis.com/what-does-smart-endpoints-and-dumb-pipes-mean/ smart endpoints and dumb pipes mean