参考：微服务架构与实践 第二章
微服务架构的“微”应该遵循的两个基本前提：
- 业务独立性。应该保证微服务是具有业务独立性的单元，并不能只是为了微而微。可以将某一领域的模型作为独立的业务单元，譬如订单、产品、合同等，也可以将某业务行为作为独立的业务单元，譬如发送邮件、单点登录验证、不同数据库之间的业务数据同步等。
- 团队自主性。团队的沟通及写作成本。当团队成员超过10人时，可以考虑划分子团队，让不同的子团队承担独立的责任。
单一职责原则，即一个对象应该只有一个发生变化的原因。对于每个服务而言，希望它处理的业务逻辑能够单一，在服务架构层面遵循单一职责原则。也就是说，微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合以及单一职责的单元，不同的服务通过管道的方式灵活组合，从而构建出庞大的系统。
轻量级通信，服务之间应通过轻量级的通信机制，实现彼此间的互通互联，互相协作。轻量级通信机制，通常指语言无关、平台无关的交互方式。对于轻量级通信的格式而言，我们熟悉的XML或者JSON，它们的解析和使用基本与语言无关、平台无关。对于轻量级的通信的协议而言，通常基于HTTP，能让服务间的通信变得标准化并且无状态化。目前，大家所熟悉的REST（Representational State Transfer），是实现服务之间互相协作的轻量级通信机制之一。
对于常见的Java RMI或者.NET Remoting等，虽然这类机制能够使用RPC的方式简化消费者端的使用，使消费者一端像调用本地接口一样调用远端的接口，但其最大的劣势在于：其对语言或者平台有较强的耦合性，同时灵活性和扩展性较差。对于微服务而言，通过使用语言无关、平台无关的轻量级通信机制，使服务于服务之间的协作变得更加标准化，也就意味着在保持服务外部通信机制轻量级的情况下，团队可以选择更适合的语言、工具或者平台来开发服务本身。
独立性，独立性指在应用的交付过程中，开发、测试以及部署的独立。在微服务架构中，每个服务都是一个独立的业务单元，当对某个服务进行改变时，对其他的服务不会产生影响。换句话说，服务和服务之间是独立的。
对于每个服务，都有独立的代码库，当对当前服务的代码进行修改后，并不会影响其他服务。从代码库的层面而言，服务于服务是隔离的。对于每个服务，都有独立的测试机制，并不比担心破坏其他功能而需要建立大范围的回归测试。也就是说，从测试的角度而言，服务和服务之间是松耦合的。
由于构建包是独立的，部署流程也就能够独立，因此服务能够运行在不同的进程中。从部署的角度考虑，服务和服务之间也是高度解耦的。
对于微服务架构中的每个服务而言，与其他服务高度解耦，只改变当前服务本身，就可以完成独立的测试、构建以及部署等。
进程隔离，所有功能都运行在同一个进程中，也就意味着，当对应用进行部署时，必须停掉当前正在运行的应用，部署完成后，再重新启动进程，无法做到独立部署。如果当前某应用中包含定时任务的功能，则要考虑在什么时间窗口适合部署，是否先停掉消息队列或者切断与数据源的联系，以防止数据被读入应用程序内存，但还未处理完，应用就被停止而导致的数据不一致性。
在微服务架构中，应用程序由多个服务组成，每个服务都是一个具有高度自治的独立业务实体。通常情况下，每个服务都能运行在一个独立的操作系统进程中，这就意味着不同的服务能非常容易地被部署到不同的主机上。
容器虚拟化技术，Docker是一个开源的应用容器引擎，允许开发者将他们的应用以及依赖包打包到一个可移植的容器中，然后发布到任何装有Docker的Linux机器上。
同传统的容器虚拟化技术相比，基于容器技术的Docker，不需要额外的hypervisor机制的支持，因此具有更高的性能和效率。另外，Docker的优势也主要体现在以下几个方面：
- 更快速地交付和部署，开发者可以使用一个标准的镜像来构建镜像，开发完成之后，运维人员可以直接使用这个镜像来部署。
- 更轻松地迁移和扩展，Docker容器可以在任意平台上运行，包括物理机、虚拟机、公有云、私有云等。这种兼容性可以低成本地将应用程序从一个平台直接迁移到另一个。
- 更简单地管理。使用Docker，所有镜像的修改都能以增量的方式被分发和更新，从而实现自动化并且高效的管理。
Docker的出现，有效地解决了微服务架构下，服务力度细、服务数量多所导致的开发环境搭建、部署以及运维成本高的问题。同时，利用Docker的容器化技术，能够实现一个节点上运行成百上千的Docker容器，每个容器都能独立地运行一个服务，因此极大降低了随着微服务数量增多所导致的节点数量增多的成本。
| SOA实现 | 微服务架构实现 |
| 企业级，自顶向下开展实施 | 团队级，自底向上开展实施 |
| 服务由多个子系统组成，粒度大 | 一个系统被拆分成多个服务，粒度细 |
| 企业服务总线，集中式的服务架构 | 无集中式总线，松散的服务架构 |
| 集成方式复杂（ESB/WS/SOAP） | 集成方式简单（HTTP/REST/JSON） |
| 单块架构系统，相互依赖，部署复杂 | 服务能独立部署 |
微服务的本质特征通常包括如下几个部分：
- 服务作为组件
- 围绕业务组织团队
- 关注产品而非项目
- 技术多样性
- 业务数据独立
- 基础设施自动化
- 演进式架构
同共享库相比，微服务是通过语言无关、平台无关的轻量级通信机制协作，因此灵活性非常高。当然，使用微服务也有它的不足之处，就是分布式调用比进程内调用更耗时间，并且严重依赖于网络的可靠性于稳定性。
业务数据独立，传统的单块应用架构，倾向于采用统一的数据存储平台来存储所有的数据。随着业务的快速发展，需求的不断变化，一方面，数据变得越来越复杂，难以管理，另一方面，随着应用系统业务逻辑的不断更新和发展，数据库不仅承担着数据存储的作用，还承担着不同系统之间的集成作用。
同时，传统的数据库大多是关系型数据库，存储的数据都是以结构化信息为主，但随着互联网的快速发展，数据的结构并不具有确定性，或者说结构发生变化的频率非常快，因此，对于如何有效维护业务数据，也成了一个难题，相应的维护成本会越来越高。
微服务架构，提倡服务自主管理其相关业务数据。这样存在几个非常明显的优势：
- 能够随着业务发展，提供业务数据接口集成，而不是以数据库的方式同其他服务集成。
- 能够随着业务的发展，选择更合适的工具管理过着迁移业务数据。
基础设施自动化，微服务架构将应用程序本身分成多个小的服务，每个服务都是一个独立的部署单元。因此，传统只需要部署一次就能上线的单块架构应用，采用微服务架构后，将需要对每个部分分别进行部署。另外，每个服务都需要部署带来的健康监控、错误回滚、日志分析等，成本也会显著增加。换句话说，部署与运维的成本会随着服务的增多呈指数级增长。因此在微服务的实践过程中，对持续交互和部署流水线的要求较高。微服务的粒度越细，就意味着需要部署的业务单元越多，业务单元，就需要更稳定的基础设置自动化机制，能够创建运行环境，安装以来，部署应用等。不过随着云技术的大规模推广与使用，部署和运维的复杂度在大幅度降低。利用云，可以快速创建系统所需要的资源，降低应用的部署成本。同时，由于持续集成、持续交付等实践的深入人心，很多团队都开始在构建软件的过程中，使用持续交付提倡的基础设施自动化技术。微服务的实践将促使企业或者团队不断寻找更高效的方式完成基础设施的自动化以及DevOps运维能力的提升。
演进式架构，微服务架构将一个复杂应用拆分成多个服务，每个服务都是一个独立的、可部署的业务单元。同时，每个服务都能独立运行在独立的进程中，并且服务之间通过轻量级的通信机制建立联系。从某种程度上而言，这些特点保证了在应用软件随着业务发展而不断变化的过程中，企业或者组织能够不断调整软件的架构，将不需要的服务（业务）抛弃，将需要的服务（业务）升级，并采用合适的技术或者工具不断优化架构，保持其处于一个不断演进的状态。
微服务的优势在于：独立性、单一职责、技术多样性。
微服务实施过程中需要考虑的因素包括：
- 分布式系统的复杂度
- 运维成本
- 部署自动化
- DevOps与组织架构
- 服务间依赖
- 服务间依赖管理
分布式系统的复杂度主要包括以下几点：
性能。同传统的单块架构相比，分布式系统由于组件与组件的调用时跨进程、跨网络的调用，因此，必然要考虑网络延迟以及宽带的影响。尤其要考虑，当某业务场景需要多个服务相互协作时，响应时间以及性能对系统的影响。
可靠性。在分布式系统中，由于网络、带宽、节点自身的可靠性等因素，然和一次组件间的远程调用都有可能失败。而且，随着微服务数量的增多，还会出现更多的潜在故障点。因此，如何提高系统的可靠性，降低由于网络、组件等引起的单点故障率，也增加了系统构建的挑战。
异步。对于跨网络的调用，需要考虑异步的通信机制。同步通信的过程一般是发送请求，接收相应并处理，整个过程实现简单，但会造成阻塞。异步通信的过程则是发送请求立即返回，不会造成阻塞，一般适用于耗时操作的处理。但异步通信在享受非阻塞的优势的同时，也大大增加了功能实现的复杂度，并且当出现缺陷时，定位问题、调试问题的难度也更大。
数据一致性。在分布式系统中，为了保证数据的一致性，通常我们会考虑使用分布式业务管理。但由于分布式事务管理需要跨多个节点来保证数据的瞬时一致性，因此比起传统的单块架构的事务，成本要高的多。另外，在分布式系统中，通常也会考虑通过数据的最终一致性来解决数据瞬时一直带来的系统不可用。
通常所说的运维成本主要包括以下几个方面：
配置：主要包括应用相关的配置信息，譬如参数、依赖部分、数据库地址、缓存地址等
部署：主要包括将应用部署到指定的环境中
监控与告警：主要包括对应用的健康状况进行监控，并当发现故障时能及时告警
日志收集：主要包括日志收集，并提供搜索等方式，帮助团队日志快速定位问题
相比传统的单块架构应用，微服务将系统分成多个独立的部分，每个部分都是可以独立部署的业务单元。这就意味着，原来适用于单块架构的集中式的部署、配置、监控或者日志收集等方式，在微服务架构下，随着服务数量的增多，每个服务都需要独立的配置、部署、监控、日志收集等，因此成本呈指数级增长。
如何有效地构建自动化部署流水线，降低部署成本、提高部署频率，是微服务架构下需要面临的一个挑战。
微服务不仅表现出一种架构模型，同样也表现出一种组织模型。这种新型的组织模型意味着开发人员和运维的角色发生的变化，开发者将承担起服务整个生命周期的责任，包括部署和监控，而运维也越来越多地表现出一种顾问式的角色，尽早考虑服务如何部署。
因此，如何在微服务的实施中，按需调整组织架构，构建全功能的团队是一个不小的挑战。
在服务数量逐渐增多的情况下，如何有效地保证服务之间能够有效按照接口的约定正常工作，成为微服务实施过程，测试面临的主要挑战。