微服务简介

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

应用架构发展

单体架构

单体应用 就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中。最终经过编译、打包，部署在一台服务器上。典型例子是j2ee的war包或ear包。

在应用的初始阶段，单体架构无论是在开发速度、运维难度上，还是服务器的成本上都有着显著的优势。在一个产品的前景不明确的初始阶段，用单体架构是非常明智的选择。随着应用业务的发展和业务复杂度的提高，这种架构明显存在很多的不足，主要体现在以下3个方面。

缺点：

随着业务扩张，开发难度加大，动一发而迁全身，代码的可读性、可维护性和可扩展性下降，业务扩展带来的代价越来越大，开发都在同一个项目改代码，相互等待，冲突不断。
部署启动时间较长，期间服务会中断，模块间相互影响较多，测试难难度加大，一个微小的问题，都可能导致整个应用挂掉。
性能容量有限，无法满足高并发下的业务需求，受单机限制（纵向扩展），有性能瓶颈。

集群架构

随着业务的发展，大多数公司会将单体应用进行集群部署，并增加负载均衡服务器（例如Nginx、F5等），以应对用户量的增加而带来的高并发访问量。此时的系统架构如图1-3所示。

优化策略：

负载均衡，通过分发服务器，将用户的访问分派到不同的应用服务器，应用服务器的负载不再成为瓶颈，用户量增加时，添加应用服务器即可。
添加缓存，使用缓存服务器来缓解数据库的数据以及数据库读取数据的压力。大多数的读取操作是由缓存完成的，但是仍然有少数读操作是从数据库读取。
读写分离，当有大量的读写操作时，将数据库进行读写分离是一个不错的选择，例如MySQL的主从热备份，通过相关配置可以将主数据库服务器的数据同步到从数据库服务器，实现数据库的读写分离，读写分离能够改善数据库的负载能力。
分区分库分表，将数据量较大的表水平或垂直切分，分散到不同的库或主机上，分散数据库的压力，提高性能。
应用拆分，将较重要或访问量较大的功能模块拆分出来作为新应用单独开发、运维。新应用与老应用间的相关依赖通过接口调用或其它方式交互。

集群有一定的处理高并发的能力，也能应对一定复杂的业务需求，改善了系统的性能，但是依然没有改变系统为单体架构的事实，此时存在的不足之处如下。

缺点：

并发容量虽有提高，但有限。虽做一定的应用拆分后，一定程度上可以缓解单体应用的问题。但随着服务拆分越来越多，开发、部署、运维、管理难度也越来越大。
持续交付能力差，业务越复杂，代码越多，修改代码和添加代码所需的时间越长。新人熟悉代码的时间长、成本高。
子应用间依赖耦合较紧，重复功能建设，重复代码等，服务间通信没有标准等。

微服务架构

“微服务”最初是由Martin Fowler 在2014年写的一篇文章《MicroServices》中提出来的。关于Martin Fowler的介绍

Martin Fowler是国际著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首
席科学家。在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都是世界顶级的
专家，现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和——集
成的公司。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者，他著有几
本经典书籍：《企业应用架构模式》、《UML精粹》和《重构》等。

相对于大规模的集群，微服务带来了质的飞越，不仅仅是服务拆分，微服务是一整套的服务治理的架构，具备整套的设施。

微服务

微服务架构领域

特性：

每个服务为独立的业务开发，单独部署，跑在自己的进程中。
自动化测试、部署、运维（ DevOps ）。
快速演化、快速迭代。
整个业务由一系列的独立的服务共同组成系统。
高度容错性、高可用、高并发。

具备能力：

注册中心：应用启动自动注册，调用方自动发现上线应用。服务异常自动隔离。
配置中心：多环境配置管理，支持在线管理配置信息，客户端实时生效。支持版本管理，快速回滚。
消息中心：服务间异步通信的总线。
负载均衡：服务调用服务会采用一定的分发策略，一般是客户端分发策略。
服务间通信：使用http或RPC协议进行服务调用，REST、gRPC、Thrift、hession等
服务降级、熔断、重试：降级，服务或依赖服务异常时，返回保底数据。熔断，若依赖服务多次失效，则断开，不再尝试调用，直接返回降级值。重试，熔断后，定期探测依赖服务可用性，若恢复则恢复调用。
服务发布与回滚：红绿部署、灰度、AB Test等发布策略，可快速回滚应用。
服务动态伸缩、容器化：根据服务负载情况，可快速手动或自动进行节点增加和减少。
服务监控与告警：服务定期健康检察、指标统计、异常告警通知运维。
请求缓存与合并：服务间调用相同请求缓存，类似请求合并成批量请求，减少服务间通信，提高性能。
服务网关：用户请求过载时进行限流、排队，过载保护，黑白名单、异常用户过滤拦截等。
服务依赖、文档、Mock Server、版本管理：自动生成接口文档，接口版本化管理，Mock接口等。
日志收集、追踪、分析：集中收集各服务日志汇总，方便排障、问题调查、应用日志分析等。
性能监测APM：对各服务性能进行监测与分析，为服务优化提供数据支持。

以上我整理的微服务相关应具备的能力，内容相当的多，要搭建这样一套完善的微服务平台，花费的财力和时间都是巨大的。幸好开源界已经在各方面有众多的可选方案。

微服务架构挑战

服务规模大，部署、运维、管理难度大。
服务间调用关系复杂，调用链路长，排障难度大。
服务间通信成本变大，性能和容错带来的挑战。
服务间依赖较多，系统集成、测试难度变大。
开发人员技术能力挑战，各服务间重复代码，重复建设等。
集群规模大，功能性能监控、告警带来的挑战。
大规模分布式，数据一致性带来的挑战。
需求和版本协调复杂度大大增加，测试难度也增加。
对基础架构要求大大提高，规模大幅增加。

微服务实施

SpringCloud

SpringCloud是在SpringBoot基础之上构建的快速开发分布式系统（微服务）的工具集。
为开发人员提供了一个开箱即用，快速构建微服务的一些通用组件（例如配置管理，服务发现，断路器，智能路由，消息总线等）。

官网

Dubbo

Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。

官网

下一代微服务Service Mesh(网格服务)

Service Mesh 架构图：

serviceMesh

Service Mesh 开源项目简介：

Linkerd（https://github.com/linkerd/li...）：

第一代 Service Mesh，2016 年 1 月 15 日首发布，业界第一个 Service Mesh 项目，由 Buoyant 创业小公司开发（前 Twitter 工程师），2017 年 7 月 11 日，宣布和 Istio 集成，成为 Istio 的数据面板。

Envoy（https://github.com/envoyproxy...）：

第一代 Service Mesh，2016 年 9 月 13 日首发布，由 Matt Klein 个人开发（Lyft 工程师），之后默默发展，版本较稳定。

Istio（https://github.com/istio/istio）：

第二代 Service Mesh，2017 年 5 月 24 日首发布，由 Google、IBM 和 Lyft 联合开发，只支持 Kubernetes 平台，2017 年 11 月 30 日发布 0.3 版本，开始支持非 Kubernetes 平台，之后稳定的开发和发布。

Conduit（https://github.com/runconduit...）：

第二代 Service Mesh，2017 年 12 月 5 日首发布，由 Buoyant 公司开发（借鉴 Istio 整体架构，部分进行了优化），对抗 Istio 压力山大，也期待 Buoyant 公司的毅力。

nginMesh（https://github.com/nginmesh/n...）：

2017 年 9 月首发布，由 Nginx 开发，定位是作为 Istio 的服务代理，也就是替代 Envoy，思路跟 Linkerd 之前和 Istio 集成很相似，极度低调，GitHub 上的 star 也只有不到 100。

微服务简介