【架构设计】微服务的4大设计原则和19个解决方案

　　作者｜郝炎峰

编辑｜小智

本文将介绍微服务架构的演进、优缺点和微服务应用的设计原则，然后着重介绍作为一个“微服务应用平台”需要提供哪些能力、解决哪些问题才能更好的支撑企业应用架构。

注：本文转载自公众号 EAWorld，已获授权。

写在前面

微服务架构现在是谈到企业应用架构时必聊的话题，微服务之所以火热也是因为相对之前的应用开发方式有很多优点，如更灵活、更能适应现在需求快速变更的大环境。

微服务平台也是我目前正在参与的，还在研发过程中的平台产品，平台是以 SpringCloud 为基础，结合了普元多年来对企业应用的理解和产品的设计经验，逐步孵化的一个微服务应用平台。

微服务架构演进过程

近年来我们大家都体会到了互联网、移动互联带来的好处，作为 IT 从业者，在生活中时刻感受互联网好处的同时，在工作中可能感受的却是来自自互联网的一些压力，那就是我们传统企业的 IT 建设也是迫切需要转型，需要面向外部客户，我们也需要应对外部环境的快速变化、需要快速创新，那么我们的 IT 架构也需要向互联网企业学习作出相应的改进，来支撑企业的数字化转型。

我们再看一下应用架构的演进过程，回忆一下微服务架构是如何一步一步进化产生的，最早是应用是单块架构，后来为了具备一定的扩展和可靠性，就有了垂直架构，也就是加了个负载均衡，接下来是前几年比较火的 SOA，主要讲了应用系统之间如何集成和互通，而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的开发、管理更加灵活高效。

微服务架构的基本思想就是“围绕业务领域组件来创建应用，让应用可以独立的开发、管理和加速”。

微服务架构的好处

　　我们总结了四个方面的优点，分别如下：

是每个微服务组件都是简单灵活的，能够独立部署。不再像以前一样，应用需要一个庞大的应用服务器来支撑。

可以由一个小团队负责更专注专业，相应的也就更高效可靠。

微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。

微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。

看到这里，大家会觉得微服务架构挺不错，然而还会有一些疑问，什么样的应用算是一个微服务架构的应用？该怎样设计一个微服务架构的应用？那我们来一起看看我们推荐的微服务应用的设计原则。

微服务应用 4 个设计原则

　　我们总结了四个原则推荐给大家：

AKF 拆分原则

前后端分离

无状态服务

Restful 通信风格

AKF 拆分原则

AKF 扩展立方体（参考《The Art of Scalability》），是一个叫 AKF 的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。

X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。

Z 轴 ：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。

Y 轴 ：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。

场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。

前后端分离

前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如 JSP ，把 Java JS HTML CSS 都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：

前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。

分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。

前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的 web UI 移动 App 等访问。

无状态服务

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。

那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

Restful 通信风格

作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实践优选的 Restful 通信风格 ，因为他有很多好处：

无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方案 HTTPS 可用。

JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。

语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些 RPC 框架生态更完善。

当然在有些特殊业务场景下，也需要采用其他的 RPC 框架，如 thrift、avro-rpc、grpc。但绝大多数情况下 Restful 就足够用了。

微服务架构带来的问题

做到了前面讲的四个原则，那么就可以说是构建了一个微服务应用，感觉上也不复杂。但实际上微服务也不是个万金油，也是有利有弊的，接下来我们来看看引入微服务架构后带来的问题有哪些。

依赖服务变更很难跟踪，其他团队的服务接口文档过期怎么办？依赖的服务没有准备好，如何验证我开发的功能。

部分模块重复构建，跨团队、跨系统、跨语言会有很多的重复建设。

微服务放大了分布式架构的系列问题，如分布式事务怎么处理？依赖服务不稳定怎么办？

运维复杂度陡增，如：部署物数量多、监控进程多导致整体运维复杂度提升。

上面这些问题我们应该都遇到过，并且也会有一些解决方案，比如提供文档管理、服务治理、服务模拟的工具和框架； 实现统一认证、统一配置、统一日志框架、分布式汇总分析； 采用全局事务方案、采用异步模拟同步；搭建持续集成平台、统一监控平台等等。

这些解决方案折腾到最后终于搞明白了，原来我们是需要一个微服务应用平台才能整体性的解决这些问题。

微服务平台的 19 个落地实践

企业 IT 建设的三大基础环境

我们先来宏观的看一下，一个企业的 IT 建设非常重要的三大基础环境：团队协作环境、个人基础环境、IT 基础设施。

团队协作环境：主要是 DevOps 领域的范畴，负责从需求到计划任务，团队协作，再到质量管理、持续集成和发布。

个人基础环境：就是本文介绍的微服务应用平台，他的目标主要就是要支撑微服务应用的设计开发测试，运行期的业务数据处理和应用的管理监控。

IT 基础设施：就是我们通常说的各种运行环境支撑如 IaaS (VM 虚拟化) 和 CaaS (容器虚拟化) 等实现方式。

微服务应用平台总体架构

微服务应用平台的总体架构，主要是从开发集成、微服务运行容器与平台、运行时监控治理和外部渠道接入等维度来划分的。

开发集成：主要是搭建一个微服务平台需要具备的一些工具和仓库

运行时：要有微服务平台来提供一些基础能力和分布式的支撑能力，我们的微服务运行容器则会运行在这个平台之上。

监控治理：则是致力于在运行时能够对受管的微服务进行统一的监控、配置等能力。

服务网关： 则是负责与前端的 WEB 应用 移动 APP 等渠道集成，对前端请求进行认真鉴权，然后路由转发。

微服务应用平台的运行视图

参考上图，在运行期，作为一个微服务架构的平台与业务系统，除了业务应用本身外，还需要有接入服务、统一门户、基础服务等平台级服务来保障业务系统的可靠运行。图中的公共服务就是业务处理过程中需要用到的一些可选服务。

微服务平台的设计目标

微服务平台的主要目标主要就是要支撑微服务应用的全生命周期管理，从需求到设计开发测试，运行期的业务数据处理和应用的管理监控等，后续将从应用生命周期的几个重要阶段切入，结合前面提到的设计原则和问题，介绍平台提供的能力支撑情况。

微服务开发：前端、后端、混合

我们一起看一下我们正在开发中的微服务应用平台 EOS8.0 的一些开发工具截图，了解一下开发期提供了哪些关键的能力支撑。

前面的设计原则中提到了一个前后端分离的原则，那么我们的开发环境中，目前支持创建前端项目、后端项目和混合项目。其中前端项目、后端项目就对应前后端分离的原则，利用平台中集成的开发工具和框架可以做到前后端开发分离，利用持续集成工具可以方便的将前端、后端项目编译打包成可独立运行的程序。混合项目则是为了兼容传统模式而保留的，为企业应用向微服务架构演进提供过渡方案。

服务契约与 API 管理

对于前面提到的微服务带来的依赖管理问题，我们可以通过平台提供的 API 管理能力来解决。说到 API 管理，那首先就用提到服务契约。平台开发工具中提供了方便的服务发布能力，能够快速的将业务功能对外发布，生成服务的规格契约，当然也可以先设计服务契约，在根据契约来生成服务的默认实现代码。

这里强调一下，我们提到的服务契约是一个很重要的东西，他有点类似 web service 的 wsdl 描述，主要描述服务接口的输入输出规格标准和其他一些服务调用集成相关的规格内容。

　　服务契约与服务模拟

有了服务契约，我们就可以根据契约自动生成服务的文档和服务模拟测试环境，这样，开发者就可以方便的获取到依赖服务变更的情况，能够及时的根据依赖服务的变化调整自己的程序，并且能够方便的进行模拟测试验证。

根据契约生成模拟服务也就是我们常说的服务挡板，这样即使依赖的其他服务还无法提供功能，我们也可以通过挡板来进行联调测试。

服务契约与服务编排

有了服务契约，那就有了服务接口的输入输出规格，那么 restful 的服务编排也就变得可行。在我们设计的契约标准中，还定义了调用集成相关的内容，比如服务支持的事务模式等等。通过这些约定，我们就可以采用简单图形化的方式来对业务服务流程进行编排。编排能够很大程度上简化分布式服务调用的复杂度，如同步、异步、异步模拟同步、超时重试、事务补偿等，均有服务编排引擎完成，不再完全依赖老师傅的编码能力。

服务编排的作用和意义很大，可以快速的将已经提供的微服务能力进行组合发布，非常适合业务的快速创新。

但是大家要注意，逻辑流编排的是业务流程，尽量能够简单明了，一眼看上去就明白业务含义。而业务规则推荐采用服务内部进行编码实现。千万不要将我们的 “逻辑流” 图形化服务编排完全取代程序编码，这样就会可能会走入另外一个极端，比如设计出像蜘蛛网一样的逻辑流图，简直就是灾难。

微服务容器

我们再来看一下微服务运行容器的一个逻辑图，大家可以看到，我们要做微服务架构的应用，可靠高效的微服务应用，实际上我们需要做的事情还是非常多的。如果没有一个统一的微服务容器，这些能力在每个微服务组件中都需要建设一遍，而且会五花八门，也很难集成到一起。有了统一的微服务运行容器和一些公共的基础服务，前面所提到的微服务架构下部分组件重复建设的问题也迎刃而解。

三方能力集成说明

我们的 API 管理契约文档 API 模拟我们是集成了 Swagger 的工具链。微服务应用平台的基础就是 SpringCloud，从容器框架到注册发现再到安全认证这些基础方案均采用了他的能力来支撑。下面简单看下我们集成的一些开源框架和工具。

SpringCloud 在微服务平台中的定位是基础框架，本文重点是要介绍一个企业级的微服务平台在落地过程中的一些设计原则和解决方案。具体 Spring Cloud 相关的技术就不在文中多做介绍了，大家可以在我们的公众号里面查看相关文章。

服务注册发现路由

接下来我们聊一下注册发现，以前的单块应用之间互相调用时配置个 IP 就行了，但在微服务架构下，服务提供者会有很多，手工配置 IP 地址又变成了一个不可行的事情。那么服务自动注册发现的方案就解决了这个问题。

我们的服务注册发现能力是依赖 SpringCloud Eureka 组件实现的。服务在启动的时候，会将自己要发布的服务注册到服务注册中心，运行时，如果需要调用其他微服务的接口，那么就要先到注册中心获取服务提供者的地址，拿到地址后，通过微服务容器内部的简单负载均衡期进行路由用。

一般情况，系统内微服务的调用都通过这种客户端负载的模式进行，否则就需要有很多的负载均衡进程。跨业务系统的服务调用，也可以采用这种去中心化的路由方式。当然采用 SOA 的模式，由中心化的服务网管来管理系统间的调用也是另一种选择，要结合企业的 IT 现状和需求来决定。

统一认证鉴权

安全认证方面，我们基于 Spring Security 结合 Auth2 再加上 JWT（Json web token）做安全令牌，实现统一的安全认证与鉴权，使得微服务之间能够按需隔离和安全互通。后续在统一认证和权限方面我们产品会陆续推出较完善并且扩展性良好的微服务组件，可以作为微服务平台的公共的认证和鉴权服务。再啰嗦一句，认证鉴权一定是个公共的服务，而不是多个系统各自建设。

日志与流水设计

作为一个微服务应用平台除了提供支撑开发和运行的技术组件和框架之外，我们还提供一些运维友好的经验总结，我们一起来看一下我们推荐的日志与流水实现，先来看日志，平台默认回会提供的日志主要有三种，系统日志，引擎日志还有跟踪日志。有了这些日志，在出问题的时候能够帮助我们获取一些关键信息进行问题定位。

要想做到出了问题能够追根溯源，那么右边的这些流水号的设计也是非常重要的，日志与各种流水号配合，能够让我们快速定位问题发生的具体时间地点以及相关信息，能够快速还原业务交易全链路。对这些日志与流水的细节处理，对于系统运维问题定位有非常大的帮助，没有这些有用的日志内容，ELK 日志收集套件搭建的再漂亮，收一对垃圾日志也是没用的。通常开源框架只是提供个框架有开发人员自由发挥，而设计一个平台则一定要考虑直接提供统一规范的基础能力。

集中配置管理

微服务分布式环境下，一个系统拆分为很多个微服务，一定要告别投产或运维手工修改配置配置的方式。需要采用集中配置管理的方式来提升运维的效率。

配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置通常是在编译部署包之前设置好。动态配置则是系统运行过程中需要调整的系统变量或者业务参数。要想做到集中的配置管理，那么需要注意以下几点：

是配置与介质分离，这个就需要通过制定规范的方式来控制。千万别把配置放在 Jar 包里；

是配置的方式要统一，格式、读写方式、变更热更新的模式尽量统一，要采用统一的配置框架；

就是需要运行时需要有个配置中心来统一管理业务系统中的配置信息，这个就需要平台来提供配置中心服务和配置管理门户。

统一管理门户

微服务架构下，一个大的 EAR、WAR 应用被拆为了多个小的可独立运行的微服务程序，通常这些微服务程序都不再依赖应用服务器，不依赖传统应用服务器的话，应用服务器提供管理控制台也就没得用了，所以微服务的运行时管理需要有统一的管理门户来支撑。我们规划了的统一集中的微服务门户，可以支撑 应用开发、业务处理、应用管理、系统监控等。上图是应用管理页面，就是对我们传统意义上的业务系统进行管理，点击一个业务系统，我们就能够看到系统下有哪些微服务，每个微服务有几个节点实例再运行，可以监控微服务的子节点状态，对微服务进行配置管理和监控。

分布式事务问题

微服务架构的系统下，进程成倍增多，那么也分布式事务一致性的问题也就更加明显。我们这里说的事务一致性，不是传统说的基于数据库实现的技术事务。微服务之间是独立的、调用协议也是无状态的，因此数据库事务方案在一开始就已经不再我们考虑的范围内。我们要解决的是一定时间后的数据达到最终一致状态，准确的说就是采用传统的业务补偿与冲正方式。

推荐的事务一致性方案有三种：

可靠事件模式：即事件的发送和接收保障高可靠性，来实现事务的一致性。

补偿模式：Confirm Cancel ，如果确认失败，则全部逆序取消。

TCC 模式：Try Confirm Cancel ，补偿模式的一种特殊实现 通常转账类交易会采用这种模式。

分布式同步调用问题

微服务架构下，相对于传统部署方式，存在更多的分布式调用，那么“如何在不确定的环境中交付确定的服务”，这句话可以简单理解为，我所依赖的服务的可靠性是无法保证的情况下，我如何保证自己能够正常的提供服务，不被我依赖的其他服务拖垮？

我们推荐 SEDA 架构来解决这个问题。

SEDA : staged event-driven architecture 本质上就是采用分布式事件驱动的模式，用异步模拟来同步，无阻塞等待，再加上资源分配隔离结起来的一个解决方案。

持续集成与持续交付设计

在运维方面，首先我们要解决的就是持续集成和持续交付，而微服务应用平台的职责范围目前规划是只做持续集成，能够方便的用持续集成环境把程序编译成介质包和部署包。（目前规划持续部署由 DevOps 平台提供相应能力，微服务平台可与 DevOps 平台集成）

这里要厘清一个概念：介质，是源码编译后的产物，与环境无关，多环境下应该是可以共用的，如：jar、dockerfile；配置：则是环境相关的信息。配置 介质 = 部署包。

获取到部署包之后，微服务应用平台的职责就完成了，接下来就是运维人员各显神通来进行上线部署操作。

微服务平台与容器云、DevOps 的关系

就微服务应用平台本身来说，并不依赖 DevOps 和容器云，开发好的部署包可以运行在物理机、虚拟机或者是容器中。

然而当微服务应用平台结合了 DevOps 和容器云之后，我们就会发现，持续集成和交付变成了一个非常简单便捷并且又可靠的过程。

简单几步操作，整套开发、测试、预发或者生产环境就能够搭建完成。整个过程的复杂度都由平台给屏蔽掉了，通过三大基础环境的整合，我们能够使分散的微服务组件更简单方便的进行统一管理和运维交付。

总结展望

我们再来回顾一下，三大基础环境的关系。微服务应用平台负责应用开发、运行以及管理；DevOps 负责项目管理、计划管理、CI、CD 和团队沟通协作等；容器云平台则负责基础设置管理，屏蔽环境的复杂度。

这三大基础环境的建设情况，直接反应出了企业 IT 能力水平。这三大基础环境是技术人员和企业都希望拥有的，是企业赢得竞争、驱动业务创新的基础，是企业加速数字化转型的必由之路。

最后，我们一起看一下普元正在研发的新一代 The Platform 平台。

上图红框中的内容是与我们今天分享的微服务应用平台相关的部分。整个 The Platform 平台是我们站在企业整体架构规划的角度，从多个维度入手，目标是为企业搭建一个持续发展的 IT 生态环境，加速企业的数字化型。

【架构】微服务架构设计

微服务

软件架构是一个包含各种组织的系统组织，这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。

Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.

（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。)

Monolithic架构

Monolithic比较适合小项目，优点是：

开发简单直接，集中式管理, 基本不会重复开发

功能都在本地，没有分布式的管理开销和调用开销。它的缺点也非常明显，特别对于互联网公司来说（不一一列举了）：

开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断

代码维护难：代码功能耦合在一起，新人不知道何从下手

部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长

稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉

扩展性不够：无法满足高并发情况下的业务需求

微服务架构

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。

相对于单体架构和SOA，它的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：

• 一组小的服务
  服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。
• 独立部署运行和扩展
  每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
• 独立开发和演化
  技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。
• 独立团队和自治
  团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

        我们可以看到整个微服务的思想就如我们现在面对信息爆炸、知识爆炸是一样的：通过解耦我们所做的事情，分而治之以减少不必要的损耗，使得整个复杂的系统和组织能够快速的应对变化。

我们为什么采用微服务呢？

"让我们的系统尽可能快地响应变化" - Rebecca Parson

让我们的系统尽可能快地去响应变化。其实几十年来我们一直在尝试解决这个问题。如果一定要在前面加个限制的话，那就是低成本的快速响应变化。上世纪90年代Kent Beck提出要拥抱变化，在同期出现了诸多轻量级开发方法（诸如 XP、Scrum）；2001年敏捷宣言诞生，之后又出现了精益、看板等新的管理方式。如果说，这些是为了尽快的响应变化，在软件开发流程和实践方面提出的解决方案，那么微服务架构就是在软件技术和架构层面提出的应对之道。

Autonomous
A Microservice is a unit of functionality; it provides an API for a set of capabilities oriented around a business domain or common utility

Isolated
A Microservice is a unit of deployment; it can be modified, tested and deployed as a unit without impacting other areas of a solution

Elastic
A Microservice is stateless; it can be horizontally scaled up and down as needed

Resilient
A Microservice is designed for failure; it is fault tolerant and highly available

Responsive
A Microservice responds to requests in a reasonable amount of time

Intelligent
The intelligence in a system is found in the Microservice endpoints not ‘on the wire’

Message Oriented
Microservices rely on HTTP or a lightweight message bus to establish a boundary between components; this ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages

Programmable
Microservices provide API’s for access by developers and administrators

Composable
Applications are composed from multiple Microservices

Automated
The lifecycle of a Microservice is managed through automation that includes development, build, test, staging, production and distribution

服务之间如何通信

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要 求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个 的开发规范和统一的服务框架时，他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能 保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要 实现幂等性，因为消息发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如 果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

微服务优点

• 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
• 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务能使用不同的语言开发。
• 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, bamboo 。
• 一个团队的新成员能够更快投入生产。
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
• 微服务允许你利用融合最新技术。
• 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
• 微服务能够即时被要求扩展。
• 微服务能部署中低端配置的服务器上。
• 易于和第三方集成。
• 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

微服务架构的缺点

• 微服务架构可能带来过多的操作。
• 需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
• 可能双倍的努力。
• 分布式系统可能复杂难以管理。
• 因为分布部署跟踪问题难。
• 当服务数量增加，管理复杂性增加。

需要考虑的问题

• 单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。
• 单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。
• 单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。
• 多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。
• 微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。
• 还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。

API为什么很重要

•服务价值的精华体现
•可靠、可用、可读
•只有一次机会

实现一个API网关作为所有客户端的唯一入口。API网关有两种方式来处理请求。有些请求被简单地代理/路由到合适的服务上，其他的请求被转给到一组服务。

相比于提供普适的API，API网关根据不同的客户端开放不同的API。比如，Netflix API网关运行着客户端特定的适配器代码，会向客户端提供最适合其需求的API。

API网关也可以实现安全性，比如验证客户端是否被授权进行某请求。

设计要素

•Version
•RequstID
•Auth&Signature
•RateLimit
•Docs
•ErrorCode&Message

微服务治理

•按需伸缩
–部署与监控运维成本
•独立部署
–机器数量与部署成本
•业务独立
–服务依赖、治理，版本管理、事务处理
•技术多样性
–环境部署成本、约定成本

•运行状态治理
–监控、限流、SLA、LB、日志分析
•服务注册与发现
•部署
–快速、复制、扩容
–单机开发
•调用
–安全、容错、服务降级、调用延时

服务容错

当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务，技术上称为1 -> N扇出. 在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源(线程，队列等)被耗尽，造成所谓的雪崩效应(Cascading Failure)，严重时可致整个网站瘫痪。

服务依赖

服务框架

1. 服务注册、发现、负载均衡和健康检查，假定采用进程内LB方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。
2. 监控日志，框架一方面要记录重要的框架层日志、metrics和调用链数据，还要将日志、metrics等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。
3. REST/RPC和序列化，框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来，HTTP/REST是当前主流API暴露方式，在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型(浏览器、普通PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出Ajax友好的JSON消息格式，而对无线设备上的Native App，框架支持输出性能高的Binary消息格式。
4. 配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。
5. 限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。
6. 管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
7. 统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。
8. 安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。
9. 文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用API的开发和测试人员带来极大便利。Swagger是一种流行Restful API的文档方案。

微服务系统底座

一个完整的微服务系统，它的底座最少要包含以下功能：

• 日志和审计，主要是日志的汇总，分类和查询
• 监控和告警，主要是监控每个服务的状态，必要时产生告警
• 消息总线，轻量级的MQ或HTTP
• 注册发现
• 负载均衡
• 部署和升级
• 事件调度机制
• 资源管理，如：底层的虚拟机，物理机和网络管理

以下功能不是最小集的一部分，但也属于底座功能：

• 认证和鉴权
• 微服务统一代码框架，支持多种编程语言
• 统一服务构建和打包
• 统一服务测试
• 微服务CI/CD流水线
• 服务依赖关系管理
• 统一问题跟踪调试框架，俗称调用链
• 灰度发布
• 蓝绿部署

容器（Docker）与微服务

•容器够小
–解决微服务对机器数量的诉求
•容器独立
–解决多语言问题
•开发环境与生产环境相同
–单机开发、提升效率
•容器效率高
–省钱
•代码/image一体化
–可复用管理系统
•容器的横向与纵向扩容
–可复制
–可动态调节CPU与内存

容器(Docker)与微服务

•Image管理
•系统安全管理
•授权管理
•系统成熟度
•社区成熟度

开发方式影响

随着持续交付概念推广以及Docker容器普及，微服务将这两种理念和技术结合起来，形成新的微服务 API 平台的开发模式，提出了容器化微服务的持续交付概念。
下图传统Monolithic的DevOps开发队伍方式：

这种整体型架构要求产品队伍横跨产品管理 Dev开发 QA DBA 以及系统运营管理，而微服务架构引入以后，如下图：

微服务促进了DevOps方式的重组，将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划分的产品队伍，以及一个大的整体的平台队伍负责运营管理，两者之间通过API交互，做到了松耦合隔绝。

• 首先需要考虑构建DevOps能力，这是保证微服务架构在持续交付和应对复杂运维问题的动力之源；
• 其次保持服务持续演进，使之能够快速、低成本地被拆分和合并，以快速响应业务的变化；
• 同时要保持团队和架构对齐。微服务貌似是技术层面的变革，但它对团队结构和组织文化有很强的要求和影响。识别和构建匹配架构的团队是解决问题的另一大支柱。
• 最后，打造持续改进的自组织文化是实施微服务的关键基石。只有持续改进，持续学习和反馈，持续打造这样一个文化氛围和团队，微服务架构才能持续发展下去，保持新鲜的生命力，从而实现我们的初衷。

    微服务的实施是有一定的先决条件：基础的运维能力（如监控、快速配置、快速部署）需提前构建，否则就会陷入如我们般被动的局面。推荐采用基础设施及代码的实践，通过代码来描述计算和网络基础设施的方法，使得图案度i可以快速安全的搭建和处理由新的配置代替的服务器，服务器之间可以拥有更高的一致性，降低了在“我的环境工作，而你的环境不工作”的可能，也是为后续的发布策略和运维提供更好的支撑。

23种设计模式总结

1.单例模式（Singleton Pattern）

通用代码：（是线程安全的）

public class Singleton {
     private static final Singleton singleton = new Singleton();
     //限制产生多个对象
     private Singleton(){
     }
     //通过该方法获得实例对象
     public static Singleton getSingleton(){
             return singleton;
     }  
     //类中其他方法，尽量是static
     public static void doSomething(){
     }
}

public class Singleton {
     private static Singleton singleton = null; 
     //限制产生多个对象
     private Singleton(){
     }  
     //通过该方法获得实例对象
     public static Singleton getSingleton(){
             if(singleton == null){
                    singleton = new Singleton();
             }
             return singleton;
     }
}

2.工厂模式

   

public class ConcreteCreator extends Creator {
public <T extends Product> T createProduct(Class<T> c){
             Product product=null;
             try {
                    product = (Product)Class.forName(c.getName()).newInstance();
             } catch (Exception e) {
                    //异常处理
             }
             return (T)product;         
     }
}

多个工厂类：

3.抽象工厂模式（Abstract Factory Pattern）

public abstract class AbstractCreator {
     //创建A产品家族
     public abstract AbstractProductA createProductA(); 
     //创建B产品家族
     public abstract AbstractProductB createProductB();
}

4.模板方法模式（Template Method Pattern）

AbstractClass叫做抽象模板，它的方法分为两类：

● 基本方法

5.建造者模式（Builder Pattern）

6.代理模式（Proxy Pattern）

● Subject抽象主题角色

抽象主题类可以是抽象类也可以是接口，是一个最普通的业务类型定义，无特殊要求。

● RealSubject具体主题角色

在该模式下，调用者只知代理而不用知道真实的角色是谁，屏蔽了真实角色的变更对高层模块的影响，真实的主题角色想怎么修改就怎么修改，对高层次的模块没有任何的影响，只要你实现了接口所对应的方法，该模式非常适合对扩展性要求较高的场合。

强制代理：

两条独立发展的线路。动态代理实现代理的职责，业务逻辑Subject实现相关的逻辑功能，两者之间没有必然的相互耦合的关系。通知Advice从另一个切面切入，最终在高层模块也就是Client进行耦合，完成逻辑的封装任务。

动态代理的意图：横切面编程，在不改变我们已有代码结构的情况下增强或控制对象的行为。

7.原型模式（Prototype Pattern）

public class PrototypeClass  implements Cloneable{
     //覆写父类Object方法
     @Override
     public PrototypeClass clone(){
             PrototypeClass prototypeClass = null;
             try {
                    prototypeClass = (PrototypeClass)super.clone();
             } catch (CloneNotSupportedException e) {
                    //异常处理
             }
             return prototypeClass;
     }
}

8.中介者模式

● Mediator 抽象中介者角色

抽象中介者角色定义统一的接口，用于各同事角色之间的通信。

● Concrete Mediator 具体中介者角色

具体中介者角色通过协调各同事角色实现协作行为，因此它必须依赖于各个同事角色。

● Colleague 同事角色

每一个同事角色都知道中介者角色，而且与其他的同事角色通信的时候，一定要通过中介者角色协作。每个同事类的行为分为两种：一种是同事本身的行为，比如改变对象本身的状态，处理自己的行为等，这种行为叫做自发行为（Self-Method），与其他的同事类或中介者没有任何的依赖；第二种是必须依赖中介者才能完成的行为，叫做依赖方法（Dep-Method）。

public abstract class Mediator {
     //定义同事类
     protected ConcreteColleague1 c1;
     protected ConcreteColleague2 c2;
     //通过getter/setter方法把同事类注入进来
     public ConcreteColleague1 getC1() {
             return c1;
     }
     public void setC1(ConcreteColleague1 c1) {
             this.c1 = c1;
     }
     public ConcreteColleague2 getC2() {
             return c2;
}
     public void setC2(ConcreteColleague2 c2) {
             this.c2 = c2;
     }
     //中介者模式的业务逻辑
     public abstract void doSomething1();
     public abstract void doSomething2();
}

9.命令模式

● Receive接收者角色

该角色就是干活的角色，命令传递到这里是应该被执行的，具体到我们上面的例子中就是Group的三个实现类（需求组，美工组，代码组）。

10.责任链模式

public abstract class Handler {
     private Handler nextHandler;
     //每个处理者都必须对请求做出处理
     public final Response handleMessage(Request request){
             Response response = null;  
             //判断是否是自己的处理级别
             if(this.getHandlerLevel().equals(request.getRequestLevel())){
                    response = this.echo(request);
             }else{  //不属于自己的处理级别
                    //判断是否有下一个处理者
                    if(this.nextHandler != null){
                            response = this.nextHandler.handleMessage(request);
                    }else{
                            //没有适当的处理者，业务自行处理
                    }
             }
             return response;
     }
     //设置下一个处理者是谁
     public void setNext(Handler _handler){
             this.nextHandler = _handler;
     }
     //每个处理者都有一个处理级别
     protected abstract Level getHandlerLevel();
     //每个处理者都必须实现处理任务
     protected abstract Response echo(Request request);
}

11.装饰模式（Decorator Pattern）

12.策略模式（Strategy Pattern）

public enum Calculator {
     //加法运算
     ADD("+"){
             public int exec(int a,int b){
                    return a+b;
             }
     },
     //减法运算
     SUB("-"){
             public int exec(int a,int b){
                    return a - b;
             }
     };
     String value = "";
     //定义成员值类型
     private Calculator(String _value){
             this.value = _value;
     }
     //获得枚举成员的值
     public String getValue(){
             return this.value;
     }
     //声明一个抽象函数
     public abstract int exec(int a,int b);
}

13.适配器模式（Adapter Pattern）

 对象适配器和类适配器的区别：

类适配器是类间继承，对象适配器是对象的合成关系，也可以说是类的关联关系，这是两者的根本区别。（实际项目中对象适配器使用到的场景相对比较多）。

14.迭代器模式（Iterator Pattern）

定义：Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.（它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。）

● Iterator抽象迭代器

抽象迭代器负责定义访问和遍历元素的接口，而且基本上是有固定的3个方法：first()获得第一个元素，next()访问下一个元素，isDone()是否已经访问到底部（Java叫做hasNext()方法）。

● ConcreteIterator具体迭代器

具体迭代器角色要实现迭代器接口，完成容器元素的遍历。

● Aggregate抽象容器

容器角色负责提供创建具体迭代器角色的接口，必然提供一个类似createIterator()这样的方法，在Java中一般是iterator()方法。

● Concrete Aggregate具体容器

具体容器实现容器接口定义的方法，创建出容纳迭代器的对象。

ps：迭代器模式已经被淘汰，java中已经把迭代器运用到各个聚集类（collection）中了，使用java自带的迭代器就已经满足我们的需求了。

15.组合模式（(Composite Pattern)）

定义：Compose objects into tree structures to represent part-whole hierarchies.Composite lets clients treat individual objects and compositions of objects uniformly.（将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。）

● Component抽象构件角色

定义参加组合对象的共有方法和属性，可以定义一些默认的行为或属性，比如我们例子中的getInfo就封装到了抽象类中。

● Leaf叶子构件

叶子对象，其下再也没有其他的分支，也就是遍历的最小单位。

● Composite树枝构件

树枝对象，它的作用是组合树枝节点和叶子节点形成一个树形结构。

树枝构件的通用代码：

public class Composite extends Component {
     //构件容器
     private ArrayList<Component> componentArrayList = new ArrayList<Component>();
     //增加一个叶子构件或树枝构件
     public void add(Component component){
             this.componentArrayList.add(component);
     }
     //删除一个叶子构件或树枝构件
     public void remove(Component component){
this.componentArrayList.remove(component);
     }
     //获得分支下的所有叶子构件和树枝构件
     public ArrayList<Component> getChildren(){
             return this.componentArrayList;
     }
}

 

使用场景：

● 维护和展示部分-整体关系的场景，如树形菜单、文件和文件夹管理。

● 从一个整体中能够独立出部分模块或功能的场景。

注意：

只要是树形结构，就考虑使用组合模式。

16.观察者模式（Observer Pattern）

定义：Define a one-to-many dependency between objects so that when one object changes state,all its dependents are notified and updated automatically.（定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。）

● Subject被观察者

定义被观察者必须实现的职责，它必须能够动态地增加、取消观察者。它一般是抽象类或者是实现类，仅仅完成作为被观察者必须实现的职责：管理观察者并通知观察者。

● Observer观察者

观察者接收到消息后，即进行update（更新方法）操作，对接收到的信息进行处理。

● ConcreteSubject具体的被观察者

定义被观察者自己的业务逻辑，同时定义对哪些事件进行通知。

● ConcreteObserver具体的观察者

每个观察在接收到消息后的处理反应是不同，各个观察者有自己的处理逻辑。

被观察者通用代码：

public abstract class Subject {
     //定义一个观察者数组
     private Vector<Observer> obsVector = new Vector<Observer>();
     //增加一个观察者
     public void addObserver(Observer o){
             this.obsVector.add(o);
     }
     //删除一个观察者
     public void delObserver(Observer o){
             this.obsVector.remove(o);
     }
     //通知所有观察者
     public void notifyObservers(){
             for(Observer o:this.obsVector){
                     o.update();
}
     }
}

 

使用场景：

● 关联行为场景。需要注意的是，关联行为是可拆分的，而不是“组合”关系。

● 事件多级触发场景。

● 跨系统的消息交换场景，如消息队列的处理机制。

注意：

● 广播链的问题

在一个观察者模式中最多出现一个对象既是观察者也是被观察者，也就是说消息最多转发一次（传递两次）。

● 异步处理问题

观察者比较多，而且处理时间比较长，采用异步处理来考虑线程安全和队列的问题。

17.门面模式（Facade Pattern）

定义：Provide a unified interface to a set of interfaces in a subsystem.Facade defines a higher-level interface that makes the subsystem easier to use.（要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。）

● Facade门面角色
客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务逻辑，只是一个委托类。
● subsystem子系统角色
可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。

使用场景：

● 为一个复杂的模块或子系统提供一个供外界访问的接口

● 子系统相对独立——外界对子系统的访问只要黑箱操作即可

● 预防低水平人员带来的风险扩散

注意：

●一个子系统可以有多个门面

●门面不参与子系统内的业务逻辑

18.备忘录模式（Memento Pattern）

定义：Without violating encapsulation,capture and externalize an object's internal state so that the object can be restored to this state later.（在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。）

● Originator发起人角色

记录当前时刻的内部状态，负责定义哪些属于备份范围的状态，负责创建和恢复备忘录数据。

● Memento备忘录角色（简单的javabean）

负责存储Originator发起人对象的内部状态，在需要的时候提供发起人需要的内部状态。

● Caretaker备忘录管理员角色（简单的javabean）

对备忘录进行管理、保存和提供备忘录。

使用场景：

● 需要保存和恢复数据的相关状态场景。

● 提供一个可回滚（rollback）的操作。

● 需要监控的副本场景中。

● 数据库连接的事务管理就是用的备忘录模式。

注意：

●备忘录的生命期

●备忘录的性能

   不要在频繁建立备份的场景中使用备忘录模式（比如一个for循环中）。

clone方式备忘录：

● 发起人角色融合了发起人角色和备忘录角色，具有双重功效

多状态的备忘录模式

● 增加了一个BeanUtils类，其中backupProp是把发起人的所有属性值转换到HashMap中，方便备忘录角色存储。restoreProp方法则是把HashMap中的值返回到发起人角色中。

BeanUtil工具类代码：

public class BeanUtils {
     //把bean的所有属性及数值放入到Hashmap中
     public static HashMap<String,Object> backupProp(Object bean){
             HashMap<String,Object> result = new HashMap<String,Object>();
             try {
                     //获得Bean描述
                     BeanInfo beanInfo=Introspector.getBeanInfo(bean.getClass());
                     //获得属性描述
                     PropertyDescriptor[] descriptors=beanInfo.getPropertyDescriptors();
                     //遍历所有属性
                     for(PropertyDescriptor des:descriptors){
                             //属性名称
                             String fieldName = des.getName();
                             //读取属性的方法
                             Method getter = des.getReadMethod();
                             //读取属性值
                             Object fieldValue=getter.invoke(bean,new Object[]{});
                    if(!fieldName.equalsIgnoreCase("class")){
                             result.put(fieldName, fieldValue);
                    }
               }
          } catch (Exception e) {
               //异常处理
          }
          return result;
     }
     //把HashMap的值返回到bean中
     public static void restoreProp(Object bean,HashMap<String,Object> propMap){
          try {
               //获得Bean描述
               BeanInfo beanInfo = Introspector.getBeanInfo(bean.getClass());
               //获得属性描述
               PropertyDescriptor[] descriptors = beanInfo.getPropertyDescriptors();
               //遍历所有属性
               for(PropertyDescriptor des:descriptors){
                    //属性名称
                    String fieldName = des.getName();
                    //如果有这个属性
                    if(propMap.containsKey(fieldName)){
                         //写属性的方法
                         Method setter = des.getWriteMethod();
                         setter.invoke(bean, new Object[]{propMap.get(fieldName)});
                    }
               }
          } catch (Exception e) {
               //异常处理
               System.out.println("shit");
               e.printStackTrace();
          }
     }
}

 

多备份的备忘录：略

封装得更好一点：保证只能对发起人可读

●建立一个空接口IMemento——什么方法属性都没有的接口，然后在发起人Originator类中建立一个内置类（也叫做类中类）Memento实现IMemento接口，同时也实现自己的业务逻辑。

19.访问者模式（Visitor Pattern）

定义：Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. （封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。）

● Visitor——抽象访问者

抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是visit方法的参数定义哪些对象是可以被访问的。

● ConcreteVisitor——具体访问者

它影响访问者访问到一个类后该怎么干，要做什么事情。

● Element——抽象元素

接口或者抽象类，声明接受哪一类访问者访问，程序上是通过accept方法中的参数来定义的。

● ConcreteElement——具体元素

实现accept方法，通常是visitor.visit(this)，基本上都形成了一种模式了。

● ObjectStruture——结构对象

元素产生者，一般容纳在多个不同类、不同接口的容器，如List、Set、Map等，在项目中，一般很少抽象出这个角色。

使用场景：

● 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作，也就说是用迭代器模式已经不能胜任的情景。

● 需要对一个对象结构中的对象进行很多不同并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。

20.状态模式（复杂）

定义：Allow an object to alter its behavior when its internal state changes.The object will appear to change its class.（当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。）

● State——抽象状态角色

接口或抽象类，负责对象状态定义，并且封装环境角色以实现状态切换。

● ConcreteState——具体状态角色

每一个具体状态必须完成两个职责：本状态的行为管理以及趋向状态处理，通俗地说，就是本状态下要做的事情，以及本状态如何过渡到其他状态。

● Context——环境角色

定义客户端需要的接口，并且负责具体状态的切换。

使用场景：

● 行为随状态改变而改变的场景

这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。

● 条件、分支判断语句的替代者

注意：

状态模式适用于当某个对象在它的状态发生改变时，它的行为也随着发生比较大的变化，也就是说在行为受状态约束的情况下可以使用状态模式，而且使用时对象的状态最好不要超过5个。

21.解释器模式（Interpreter Pattern）（少用）

定义：Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.（给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。）

● AbstractExpression——抽象解释器

具体的解释任务由各个实现类完成，具体的解释器分别由TerminalExpression和Non-terminalExpression完成。

● TerminalExpression——终结符表达式

实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。具体到我们例子就是VarExpression类，表达式中的每个终结符都在栈中产生了一个VarExpression对象。

● NonterminalExpression——非终结符表达式

文法中的每条规则对应于一个非终结表达式，具体到我们的例子就是加减法规则分别对应到AddExpression和SubExpression两个类。非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式。

● Context——环境角色

具体到我们的例子中是采用HashMap代替。

使用场景：

● 重复发生的问题可以使用解释器模式

● 一个简单语法需要解释的场景

注意：

尽量不要在重要的模块中使用解释器模式，否则维护会是一个很大的问题。在项目中可以使用shell、JRuby、Groovy等脚本语言来代替解释器模式，弥补Java编译型语言的不足。

22.享元模式（Flyweight Pattern）

定义：Use sharing to support large numbers of fine-grained objects efficiently.（使用共享对象可有效地支持大量的细粒度的对象。）

对象的信息分为两个部分：内部状态（intrinsic）与外部状态（extrinsic）。

● 内部状态

内部状态是对象可共享出来的信息，存储在享元对象内部并且不会随环境改变而改变。

● 外部状态

外部状态是对象得以依赖的一个标记，是随环境改变而改变的、不可以共享的状态。

● Flyweight——抽象享元角色

它简单地说就是一个产品的抽象类，同时定义出对象的外部状态和内部状态的接口或实现。

● ConcreteFlyweight——具体享元角色

具体的一个产品类，实现抽象角色定义的业务。该角色中需要注意的是内部状态处理应该与环境无关，不应该出现一个操作改变了内部状态，同时修改了外部状态，这是绝对不允许的。

● unsharedConcreteFlyweight——不可共享的享元角色

不存在外部状态或者安全要求（如线程安全）不能够使用共享技术的对象，该对象一般不会出现在享元工厂中。

● FlyweightFactory——享元工厂

职责非常简单，就是构造一个池容器，同时提供从池中获得对象的方法。

享元工厂的代码：

public class FlyweightFactory {
     //定义一个池容器
     private static  HashMap<String,Flyweight> pool= new HashMap<String,Flyweight>();
     //享元工厂
     public static Flyweight getFlyweight(String Extrinsic){
             //需要返回的对象
             Flyweight flyweight = null;
             //在池中没有该对象
             if(pool.containsKey(Extrinsic)){
                     flyweight = pool.get(Extrinsic);
             }else{
                     //根据外部状态创建享元对象
                     flyweight = new ConcreteFlyweight1(Extrinsic);
                     //放置到池中
                     pool.put(Extrinsic, flyweight);
             }
             return flyweight;
     }
}

使用场景：

● 系统中存在大量的相似对象。

● 细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份。

● 需要缓冲池的场景。

注意：

● 享元模式是线程不安全的，只有依靠经验，在需要的地方考虑一下线程安全，在大部分场景下不用考虑。对象池中的享元对象尽量多，多到足够满足为止。

● 性能安全：外部状态最好以java的基本类型作为标志，如String，int，可以提高效率。

23.桥梁模式（Bridge Pattern）

定义：Decouple an abstraction from its implementation so that the two can vary independently.（将抽象和实现解耦，使得两者可以独立地变化。）

设计原则：

【公众号】说说技术总监三板斧（十年肺腑之言）

技术人员职业发展路线图，按照管理路线和技术路线区分。在国外管理路线和技术路线的职位会按照IT Manager和TechLead去区分，但在国内其实是没有纯粹的管理路线，管理岗位中一定有具体技术工作的要求。今天我说说对“技术总监”岗位职能要求的理解。

我理解技术总监的权责范畴应该包括技术性工作和管理性工作，管理性工作又分为人员管理（即团队管理）和项目管理。在技术型工作中，我认为更多考验的是一个技术管理者的技术深度和广度，而管理性工作中，更多考验的是一个技术管理者对于复杂人和事的协调能力。

对于一位优秀的技术人员而言，应该具备几种技术能力，包括：关键性技术能力、架构设计能力、工程管理能力；而一位技术管理者首先应该是一名优秀的技术人员，必须能在这三种技术能力之间游刃有余。

你也可以把它理解为技术难点的攻克。我曾看到过朋友圈包括饿了么CTO张雪峰、钉钉CTO一粟等，在团队面前现场coding演示某些难啃骨头的解决场景。不要求技术管理者写代码，但是在某些风险性大的技术场景里，技术管理者必须能亲自上阵，以免团队成员解决不了“甩锅”的时候可以接得起来。而且了解团队的代码情况，融入团队的代码编写，也方便对系统架构的掌控。另外，作为示范代码，能够让管理者在团队中更好的立威。

我们在说到架构设计的时候，一般会提到“技术架构”和“业务架构”，脱离业务架构的技术架构一定不会成功。这就要求技术管理者对业务有良好的理解能力。而且架构的设计不仅仅是指能画架构图，能写架构文档，能把热门技术堆砌到图纸上；一个没在工地上跑过的建筑设计师一定不会造出好的大楼。反之，一个不做架构设计就想写出好系统的技术人员不是天才就是傻子。架构的设计要更好的考虑运行效率、业务的可拓展性/伸缩性，特殊场景的分模块管理等；如果做不到这些，系统将随业务的进展越来越冗余，最终将为如何“解耦”操碎心，“重构”往往就在这样的场景下被提出来，这其实是对系统和业务的具有伤害性的选择。

所以作为技术总监，必须要有大的视野去组织模块和架构，避免早期的设计缺陷造成痛苦不堪的晚期“重构”。

很多人对“工程管理能力”感到陌生，如果我把这块分开说为“性能”、“运维”和“效率”大家就好理解了。我们更多的认为工程管理能力关系到稳定性和效率上。小团队当中，工程管理能力往往价值体现不大，但当遇到一个大团队的时候，大团队的运转稳定性和效率就会成为突出问题。这里面主要包括持续性优化的能力和工具化使用的能力。并且需要较多的靠近流程管理和业务理解，有比较多的细小和琐碎事情。我见过很多技术管理者开发出身，但是晋升到管理者的岗位后，不得不去了解运维之类的事情。这些都属于工程管理能力的范畴。

很多技术人员都很厌恶管理工作，让一个常年跟没有脾气和情绪的机器打交道的技术人员，去应付心思千万的人员管理，听上去确实很有挑战。但你要知道，管理的目标是实现组织目标，最重要的是制定管理标准、贯彻执行和校验结果。而这些也并非非要管理者亲力亲为，我们在组织的构建中强调的搭班子，就可以安排一些在这方面擅长的人以“副总监”甚至是“项目经理”“助理”的职位存在。

我觉得一个技术总监要分出30%-40%的精力在团队的管理工作上，主要包括这些方面：

关于技术人员的KPI一直是一个千古难题，并且热度不减。难就难在技术人员工作的质量难以量化，并且受不可控因素的影响太多。我认为给技术人员的绩效指标达到两个目的即可，一个是量化可量化的东西，一个是鼓励他的积极性。

所谓量化可量化的东西，通常我们会认为是指在时间进度上量化或者bug数量、项目数量等；但其实也可以将能保证“质量”的因素模块化，分模块量化，当然这个要求比较高，因为所谓保证质量的模块，是需要技术总监确定至少是建议性，而不是丢给技术人员自行设置，比如设置必须要完成的单元测试指标、质量监控指标等。

很多人会问需不需要在技术人员的考核指标中设置业务指标，我认为在业务相对稳定的情况下是有一定可行性的，可以帮助技术人员更好的理解大团队的目标，知道在业务环节中技术价值的体现，更好的发挥主动能动性。

我认为组织结构设计更好的关乎团队的效率和能力发挥，包括岗位的增删减，扁平化结构还是梯度化结构，什么样的人安插在什么样的岗位上，这也是管理者应该懂得一门大课程。

而招聘上，我只想说，对于技术总监而言抓重点岗位，普通岗位的招聘可以由经理去进行，但不要小觑招聘，寻找团队平均能力以上的人是一个团队走的远的基础。

我比较在乎这点，就像我并不认为一个人的成长是顺其自然，我认为每个人的成长中都是受到重要的人和事的影响的。环境对于一个人的成长非常重要，要尽可能的去创造可持续成长的环境。包括：

1.code review，我认为有必要性；

2. 技术团队内部技术方案的评审，最好的学习往往源于把手里的工作做好；

3. 外部的学习和讲座，最怕坐井观天，最后被时代抛弃，不要抱着工作不放，要想象一下未来的世界和你的位置。

对于技术总监而言，除了处理部门内的事情，部门外的事情也需要一定的协调沟通，但是我并不建议多花时间在外部的会议和沟通上，更多的沟通是跟随项目走，由项目负责人去跟进和反馈即可。你只需要协调那些别人要不来的资源，当然你能要的来，大部分原因是因为你在公司的威信你曾给过别人的帮助。

很多公司会设立有项目经理的角色，这块就不怎么需要技术总监来操心；但反过来讲，每一位技术人员也都身兼项目经理的角色，而技术总监一定是最大的项目负责人。有关项目的事情会比较琐碎，但完全可以按照项目负责人分配下去，技术总监需要的是指定负责人、过问项目计划和进度，另外就是在项目推进遇到阻力的时候，去解决问题。主要包括这两方面：

第一，项目进度

1. 项目评审，确定项目计划；

2. 检查进度，进度延迟预警

3. 项目验收和总结

第二，资源协调

1. 人员协调，包括项目组人员以及编外人员的支持

2. IT设施协调，包括硬件、软件系统等，公司内资源还有公司外资源

有一种说法，领导就是要拿别人拿不到的资源，做别人做不了的决定，承担别人承担不了的责任。

但是，我想说技术管理者难度更胜一层，技术管理者是要先有专业性，再来领导力，是需要像医者一样的仁心仁术，而不是简单粗暴的工厂管理。

我也不认同很多人认为随着时间的增长，技术人终将成为技术管理者，否则何来的“中年危机”，不是时间的累积就能得到质的变化。我身边也有很多技术管理者经常感叹：“感觉自己做到技术总监就到头了，未来乏力。”只想说，从技术能力的成长，到复杂事物管理能力的成长，再到视野和决策能力的成长，这才是一个技术人员，从程序员到中层管理者（技术总监）再到高层管理者（CTO）的能力成长过程。

如果你觉得乏力，或许应该多出来看看，毕竟有些东西是靠钻研出来的，有些东西是靠多行路、多交流得出来的，比如情商和视野，见闻的东西多了就知道该如何处理了。

大型互联网架构演化

前言

一个成熟的大型网站（如淘宝、京东等）的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性，它总是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随业务扩展而完善出来的，并不是一蹴而就；不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿的用户实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段可以广泛运行在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。

一、最开始的网站架构

最初的架构，应用程序、数据库、文件都部署在一台服务器上，如图：

二、应用、数据、文件分离

随着业务的扩展，一台服务器已经不能满足性能需求，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。

三、利用缓存改善网站性能

在硬件优化性能的同时，同时也通过软件进行性能优化，在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则（即80%的访问请求，最终落在20%的数据上），所以我们可以对热点数据进行缓存，减少这些数据的访问路径，提高用户体验。

缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理等，这个后面再讲。本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，OSCache就是常用的本地缓存组件。本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。

四、使用集群改善应用服务器性能

应用服务器作为网站的入口，会承担大量的请求，我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求，根据分发策略将请求分发到多个应用服务器节点。

常用的负载均衡技术硬件的有F5，价格比较贵，软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡，根据目标地址和端口选择内部服务器，Nginx是七层负载均衡和HAProxy支持四层、七层负载均衡，可以根据报文内容选择内部服务器，因此LVS分发路径优于Nginx和HAProxy，性能要高些，而Nginx和HAProxy则更具配置性，如可以用来做动静分离（根据请求报文特征，选择静态资源服务器还是应用服务器）。

五、数据库读写分离和分库分表

随着用户量的增加，数据库成为最大的瓶颈，改善数据库性能常用的手段是进行读写分离以及分表，读写分离顾名思义就是将数据库分为读库和写库，通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分，水平切换则是对一个数据库特大的表进行拆分，例如用户表。垂直切分则是根据业务不同来切换，如用户业务、商品业务相关的表放在不同的数据库中。

六、使用CDN和反向代理提高网站性能

假如我们的服务器都部署在成都的机房，对于四川的用户来说访问是较快的，而对于北京的用户访问是较慢的，这是由于四川和北京分别属于电信和联通的不同发达地区，北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器，返回路径也一样，所以数据传输时间比较长。对于这种情况，常常使用CDN解决，CDN将数据内容缓存到运营商的机房，用户访问时先从最近的运营商获取数据，这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。

而反向代理，则是部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有没有缓存数据才会继续走应用服务器获取，也减少了获取数据的成本。反向代理有Squid，Nginx。

七、使用分布式文件系统

用户一天天增加，业务量越来越大，产生的文件越来越多，单台的文件服务器已经不能满足需求。需要分布式的文件系统支撑。常用的分布式文件系统有NFS。

八、使用NoSql和搜索引擎

对于海量数据的查询，我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb和redis，搜索引擎有lucene。

九、将应用服务器进行业务拆分

随着业务进一步扩展，应用程序变得非常臃肿，这时我们需要将应用程序进行业务拆分，如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者同享数据库来实现。

十、搭建分布式服务

这时我们发现各个业务应用都会使用到一些基本的业务服务，例如用户服务、订单服务、支付服务、安全服务，这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。淘宝的Dubbo是一个不错的选择。

小结

大型网站的架构是根据业务需求不断完善的，根据不同的业务特征会做特定的设计和考虑，本文只是讲述一个常规大型网站会涉及的一些技术和手段。