enlyhua的专栏

第　12 章 高级案例实战　12.1　案例 1：智能路由　 通过智能路由使部分用户使用新版本加以验证。 12.1.1　插件需求　 12.1.2　插件开发　 12.1.3　插件部署　 12.1.4　插件配置　 12.1.5　插件验证　12.2　案例 2：动态限频　 动态限频插件可以控制微服务站点的请求流量。当微服务站点面对大流量访问的时候，可以通过动态限频插件在网关层面对请求流量进行并发控制，以防止大流量对后端核心服务造成影响和破坏，从而导致系统被拖垮且不可用。换言之就是通过调节请求.

11.1　简介　 kong 的自定义插件由一组Lua模块文件组成，其中每个文件均可以被视为一个独立的模块，实现独立的功能。插件的模块文件名遵循下面的约定： kong.plugins.<plugin_name>.<module_name> 其中 plugin_name 是自定义插件的名称，module_name 是模块文件的名称。 在kong内部，我们使用 lua_package_path 所设置的路径来搜索和加载所需的模块文件。除此之外，我们还需要将插件的名称添加到配置.

第　10 章 内置插件 插件是代理请求和响应的生命周期内执行的lua代码，既可以添加到服务和路由中，也可以关联到特定的消费者。10.1　插件分类 主要有7类： 1.身份验证 2.安全防护 3.流量控制 4.无服务器架构 5.分析监控 6.信息转换器 7.日志记录 　10.2　环境准备　10.3　身份验证　 10.3.1　基本身份验证 在服务或者路由中添加 基本身份验证(Basic Auth)插件后，如果客户端想访问，就需要提供用户名和密码。此插件会检查请求.

9.1　负载均衡的原理　 kong 为后端服务器节点提供了2种负载均衡策略，一种是直接基于dns的策略，另外一种是动态的环形均衡器策略，其中后者无需dns服务器即可进行服务的注册与发现。 9.1.1　基于 DNS 的负载均衡　 当服务中的host属性不能被解析为上游名称或此host属性的名称并不在本地的 DNS host 文件中，且服务中的host属性是名称而不是ip地址时， kong会自动选择基于dns的负载均衡策略。 当使用基于dns的负载均衡策略时，后端服务的注册是在kong外部.

第　8 章 指标监控与报警　 常见的监控指标有，cpu使用率，内使用率，GC，磁盘IO，网络流量，网络延迟，请求速度，请求排队，链接数，用户态与内核态的上下文切换等。 指标监控和报警主要分为以下6个方面： 1.采集指标数据 2.存储指标数据 3.分析指标数据 4.展示指标数据 5.监控指标数据 6.报警处理8.1　Kong 的监控指标　8.2　Prometheus　 开源的监控，报警，时间序列数据库的组合。 8.2.1　安装　 8.2.2　配置　 8.2..

7.1　日志的分类与配置　7.1.1　访问日志的属性　7.1.2　访问日志的配置　7.1.3　错误日志的配置　7.2　ELK Filebeat 的选择　7.3　Filebeat　7.3.1　安装　7.3.2　配置　7.3.3　启动　7.4　Elasticsearch　7.4.1　安装　7.4.2　配置　7.4.3　启动　7.5　Logstash　7.5.1　安装　7.5.2　配置　7.5.3　启动　7.6　Kibana　7.6.1　安装　7.6.2　配置　7.6.3.

6.1　简介　6.2　环境　 yum install libtermcap-dev ncuress-devel libevent-devel readline-devel curl -R -O http://www.lua.org/ftp/lua-5.3.5.tar.gz tar zxf lua-5.3.5.tar.gz cd lua-5.3.5 make linux test ls -s ~/lua5.3.5/src/lua /usr/bin/lua lua6.3　注.

第　5 章 Kong 的配置详解　 配置文件主要分为9大类： 1.常规通用配置 2.nginx通用配置 3.指令注入配置 4.数据存储配置 5.存储缓存配置 6.DNS解析配置 7.路由同步配置 8.Lua综合配置 9.混合模式配置5.1　常规通用配置　5.2　Nginx 通用配置　 5.2.1　代理 / 监听类　 5.2.2　工作进程类　 5.2.3　请求类　 5.2.4　SSL/TLS 类　 5.2.5　真实 IP 类　 5.2.6　其他类　.

第４章　Kong 的基本功能　 路由转发，负载均衡，灰度发布，蓝绿部署，正则路由，https跳转，混合模式，tcp流代理。4.1　路由转发　 创建一个名为 helloworld 的路由转发服务，效果是请求到 example.com，会打开 helloworld.com。 4.1.1　配置服务　 curl -i -X POST --url http://localhost:8001/services/ --data 'name=example-service' --data 'url=http.

3.1　Konga 介绍　 通过 Konga 和 Kong Admin API 完成的操作都是即时生效的。3.2　源码安装　 3.2.1　安装 Git 和 Node.js　 curl --silent --location https://rpm.nodesource.com/setup_10.x | sudo bash yum install -y nodejs 3.2.2　安装 Konga　 git clone https://github.com/pantsel/konga..

2.1　Kong 的安装部署 2.1.1　环境介绍　 2.1.2　直接安装　 yum install epel-release yum install kong-2.0.0.el7.amd64.rpm --nogpgcheck kong version 2.1.3　容器安装　 docker pull kong:2.0 2.1.4　Kubernetes 安装　2.2　Kong 数据库的安装部署　 kong 数据库支持 PostgreSQL,Cassandra和DB-less.

1.1　网关　 网关是一种高性能，低延迟的流量负载均衡服务，是大型分布式系统中用来保护内部服务的一道安全屏障。它可以对请求实施统一拦截，帮助开发人员轻松的向外界提供服务，是的开发人员不必考虑 路由，版本，缓存，认证，授权，身份验证，限流，熔断，灰度，过滤，转换，计费，审计，脱敏，日志和监控等事情，只需要专注于业务的实现即可。除了将网关应用于常见的代理服务之外，还可以广泛应用于 waf,cdn，边缘计算，IoT等。1.2　微服务　 客户端和服务端之间的流量叫做 南北流量，不同服务器之间的流量叫做.

8.1 什么是敏捷开发2.0 8.1.1 常用的4种开发模式 8.1.2 什么是DevOps 8.1.3 敏捷开发2.0解决的问题8.2 敏捷开发的自动化流程 8.2.1 持续集成 8.2.2 持续交付和持续部署 8.3 敏捷开发的常用自动化工具 8.3.1 分布式版本控制工具Git 8.3.2 持续集成和持续交付工具Jenkins 8.3.3 基础平台管理工具SaltStack 8.3.4 Docker容器化工具.

7.1 容器vs虚拟机 7.1.1 什么是虚拟机 7.1.2 什么是容器 7.1.3 容器和虚拟机的区别 7.1.4 容器主要解决的问题 7.1.5 Docker的优势 7.2 Docker实战 7.2.1 Docker的架构 7.2.2 Docker的安装 7.2.3 Docker初体验 7.2.4 Docker后台服务的管理 7.2.5 Docker的客户端命令 7.2.6 Docker Compose编排工具的使用 7.3 容器化项目 7.3.

6.1 海恩法则和墨菲定律 6.2 线上应急的目标、原则和方法 6.2.1 应急目标 6.2.2 应急原则 6.2.3 线上应急的方法和流程 6.3 技术攻关的方法论 6.4 环境搭建和示例服务启动 6.5 高效的服务化治理脚本 6.5.1 show-busiest-java-threads 6.5.2 find-in-jar 6.5.3 grep-in-jar 6.5.4 jar-conflict-detect 6.5.5 http-spy 6.5.6.

5.1 APM系统简介 5.1.1 优秀的开源APM系统 5.1.2 国内商业APM产品的介绍 5.2 调用链跟踪的原理 5.2.1 分布式系统的远程调用过程 5.2.2 TraceID 5.2.3 SpanID 5.2.4 业务链 5.3 调用链跟踪系统的设计与实现 5.3.1 整体架构 5.3.2 TraceID和SpanID在服务间的传递 5.3.3 采集器的设计与实现 5.3.4 处理器的设计与实现 5.3.5 调用链系统的展示 5.4 本章小结 .

4.1 开源日志框架的原理分析与应用实践 4.1.1 JDK Logger 4.1.2 Apache Commons Logging 4.1.3 Apache Log4j 4.1.4 Slf4j 4.1.5 Logback 4.1.6 Apache Log4j 4.2 日志系统的优化和最佳实践 4.2.1 开发人员的日志意识 4.2.2 日志级别的设置 4.2.3 日志的数量和大小 4.2.4 切割方式 4.2.5 日志格式的配置 4.2.6 一行日志导致.

3.1 架构设计与非功能质量3.2 全面的非功能质量需求3.2.1 非功能质量需求的概述3.2.2 非功能质量需求的具体指标3.3 典型的技术评审提纲3.3.1 现状3.3.2 需求3.3.3 方案描述3.3.4 方案对比3.3.5 风险评估 3.3.6 工作量评估 3.4 性能和容量评估经典案例 3.4.1 背景 3.4.2 目标数据量级 3.4.3 量级评估标准 3.4.4 方案 3.4.5 小结 3.5 性能评估参考标准 3.5.1 常用的应用层性能指标参考标准 .

2.1 什么是一致性 2.2 一致性问题 2.3 解决一致性问题的模式和思路 2.3.1 酸碱平衡理论 2.3.2 分布式一致性协议 2.3.3 保证最终一致性的模式 2.4 超时处理模式 2.4.1 微服务的交互模式 2.4.2 同步与异步的抉择 2.4.3 交互模式下超时问题的解决方案 2.4.4 超时补偿的原则 2.5 迁移开关的设计 2.6 本章小结.

第1章 分布式微服务架构设计原理1.1 从传统单体架构到服务化架构1.1.1 JEE架构1.1.2 SSH架构1.1.3 服务化架构1.2 从服务化到微服务 1.2.1 微服务架构的产生 1.2.2 微服务架构与传统单体架构的对比 1.2.3 微服务架构与SOA服务化的对比 1.3 微服务架构的核心要点和实现原理 1.3.1 微服务架构中职能团队的划分 1.3.2 微服务的去中心化治理 1.3.3 微服务的交互模式 1.3.4 微服务的分解和组合模式 1.3.5 微服务的容错模.

10.1　版本控制的基本要素 10.1.1　Web服务版本控制 10.1.2　REST服务版本控制 10.1.3　粒度的精细与粗糙限制 10.2　版本控制和兼容性 10.2.1　后向兼容 10.2.2　前向兼容 10.2.3　兼容性变更 10.2.4　非兼容性变更 10.3　REST　服务兼容性关注点 10.4　版本标识符 10.5　版本控制策略 10.5.1　严格策略（新变更，新契约） 10.5.2　弹性策略（后向兼容） 10.5.3　松散策略（反.

9.1　服务模型设计关注点 9.1.1　实体服务设计 9.1.2　公共服务设计 9.1.3　微服务设计 9.1.4　任务服务设计9.2　REST服务设计指南 9.2.1　统一服务契约设计关注点 9.2.2　设计和标准化方法 9.2.3　设计和标准化HTTP报头 9.2.4　设计和标准化HTTP响应码 9.2.5　自定义响应码 9.2.6　设计媒介类型 9.2.7　设计媒介类型模式 9.2.8　复杂方法设计 9.2.9　无状态复杂方法 9.2.10.

8.1　服务模型设计关注点 8.1.1　实体服务设计 8.1.2　公共服务设计 8.1.3　微服务设计 8.1.4　任务服务设计 8.2　Web服务设计指南 8.2.1　应用命名标准 8.2.2　应用合适的服务契约API粒度 8.2.3　将Web服务的操作设计成原生可扩展的 8.2.4　考虑采用模块化WSDL文档 8.2.5　慎用命名空间 8.2.6　使用SOAP文档和Literal属性值 .

7.1　REST服务建模过程 7.1.1　步骤1：分解业务流程（使之成为细粒度操作） 7.1.2　步骤2：滤掉不适操作 7.1.3　步骤3：定义候选实体服务 7.1.4　步骤4：识别特定流程逻辑 7.1.5　步骤5：识别资源 7.1.6　步骤6：将服务能力与资源和方法相关联 7.1.7　步骤7：应用面向服务 7.1.8　步骤8：识别候选服务组合 7.1.9　步骤9：分析处理需求 7.1.10　步骤10：定义候选公共服务（并且关联资源和方法） 7.1.11　步骤..

6.1　Web服务建模过程 6.1.1　步骤1：分解业务流程（使之成为细粒度操作） 6.1.2　步骤2：过滤不适操作 6.1.3　步骤3：定义候选实体服务 6.1.4　步骤4：识别特定流程逻辑 6.1.5　步骤5：应用面向服务 6.1.6　步骤6：识别候选服务组合 6.1.7　步骤7：分析处理需求 6.1.8　步骤8：定义候选公共服务 6.1.9　步骤9：定义候选微服务 6.1.10　步骤10：应用面向服务 6.1.11　步骤11：修订候选服务组合 6.1.12　步.

5.1　服务层次简介 5.1.1　服务模型和服务层次 5.1.2　服务和候选服务能力5.2　分解业务问题 5.2.1　功能分解 5.2.2　服务封装 5.2.3　不可知上下文 5.2.4　不可知能力 5.2.5　功能抽象 5.2.6　实体抽象 5.2.7　非不可知上下文 5.2.8　微任务抽象和微服务 5.2.9　流程抽象和任务服务5.3　构建面向服务的解决方案 5.3.1　面向服务和服务组合 5.3.2　能力组合和能力再组合 5.3.3　逻辑集中与服务规范化..

4.1　SOA的4个特性 4.1.1　业务驱动 4.1.2　供应商中立 4.1.3　企业中心化 4.1.4　组合中心化 4.1.5　设计优先级4.2　SOA的4种常见类型 4.2.1　服务架构 4.2.2　服务组合架构 4.2.3　服务目录架构 4.2.4　面向服务的企业架构 4.3　面向服务和SOA的最终结果 4.4　SOA项目和生命周期 4.4.1　方法论和项目交付的策略 4.4.2　SOA项目阶段 4.4.3　SOA项目采用的计划 4..

理解面向服务

1.入口 入口是一个封装外部系统或资源访问的对象。 当访问这种外部资源的时候，通常需要获得他们的api。但是这些api可能具有天然的复杂性，因为他们必须考虑到资源自身的特性。任何人要理解一个资源就必须通晓其api， 无论是针对关系数据库jdbc还是sql，还是针对xml的w3c和jdom，皆是如此。这不仅使得软件可读写差，也使得软件的修改变得很困难，例如将来在某个时刻把关系数据库中的 ...

1.客户会话状态 将会话状态保存在客户端。 1.运行机制 即使是最面向服务器的设计也至少要用到一些客户会话状态，哪怕是用来记录会话标识号。有的应用中可以考虑把所有的会话状态都保存到客户端，这种情况下，客户端 每次请求都把所有的会话数据传给服务器，服务器在每次响应时把所有的会话状态传给客户。这样的服务器可以是完全无状态的。 通常使用数据传输对象来传输数据。数据传输对象可以在...

1.远程外观 为细粒度对象提供粗粒度的外观来改进网络上的效率。 在面向对象模型中，经常有很多规模较小的对象，它们有较小的方法。这样就提供了很多机会来控制和替换某些行为，还可以用良好的命名使应用程序更容易理解。 然而，这种小粒度动作将导致大量对象间的交互，而且这些交互通常需要很多的方法调用。 在一个单一的地址空间内，小粒度的交互工作的很好，但是当你在两个进程之间做调整时这种良好的状态...

1.乐观离线锁 通过冲突检测和事务回滚来防止并发业务事务中的冲突。 一个业务事务的执行通常需要跨越一系列的系统事务。而一旦超出单个系统事务的范围，就不能仅仅依靠数据库管理程序来确保业务事务将会使记录数据处于一致的状态。 当两个会话同时处理同样的记录时很难保证数据的完整性，还可能丢失对数据的更新。当某个会话正在编辑数据时，其他的会话可能读到不一致的数据。 用乐观离线锁可以解决这个问题...

1.模型-视图-控制器 把用户界面交互拆分到不同的三种角色中。 1.运行机制 MVC包括3个角色。模型：一个表示领域信息的对象，它是一个不可见对象，包括除了用于UI的那部分数据和行为之外的所有的数据和行为。在纯面向对象的概念里，模型是 领域模型中的一个对象。视图表示UI中模型的显示。因此，加入我们的模型是一个客户对象，那么我们的视图可能充满着UI窗口小部件或者是一个HTML页面，这些...

1.元数据映射 在元数据中保持关系---对象映射的详细信息。 大部分用来处理对象---关系映射的代码都描述了如何把数据库中的域对应到内存对象中的域。 1.运行机制 使用元数据映射最主要的决策是如何根据运行代码来表示元数据中的信息。有2种主要途径：代码生成和反射编程。 使用代码生成时需要写这样一个程序：输入是元数据，输出是映射实现类的源代码。这些类看上去是手写的，但事实上完全是构建...

1.标识域 为了在内存对象和数据库行之间维护标识而在对象内保存的一个数据库标识域。 关系数据库通过使用键尤其是主键来区分数据行。然而，内存对象不需要这样一个键，因为对象系统能够保证正确的身份确认(在C++中是直接用原始内存的位置)。在数据库中读取 数据非常方便，但是为了顺序写回这些数据，需要把数据库和内存对象系统联系在一起。 本质上，标识域是非常简单的。你要做的所有工作只是将关系数...

1.工作单元 维护受业务事务影响的对象列表，并协调变化的写入和并发问题的解决。 从数据库中存取数据时，记录所修改的内容是非常重要的；否则，那些改变的数据将不会被写回到数据库中。同样，必须插入创建的新对象和移除已删除的对象。 可以在每次修改对象模型时对数据库进行相应的修改，但这样会产生大量规模很小的数据库调用，从而导致速度变慢。而且这样做还需要有一个对整个交互过程都开发的事务。 如果存...

1.表数据入口 充当数据库表访问入口的对象，一个实例处理表中所有的行。 表数据入口包含了用于访问单个表或视图的所有sql，如选择，插入，更新，删除等。其他代码调用它的方法来实现所有与数据库的交互。 1.运行机制 表数据接口很简单，一般包括几个从数据库中获取数据的查找方法以及更新，插入和删除方法。每个方法都将输入参数映射为一个sql调用并在数据库连接上执行该语句。 由于表数据如克...

1.事务脚本 使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求。 大多数业务应用都可以被看做是一系列的事务。一个事务可能将某种信息看做是以特定方式组织的，然后另一事务则会改变它。在客户系统和服务器系统之间的每次 交互都包含一定数量的逻辑。 事务脚本将所有这些逻辑组织成单个过程，在过程中直接调用数据库，或者只通过一个简单的数据库封装器。每个事务都有自己的事务脚本，尽管事务间的...

极限编程，持续集成，测试驱动开发，重构。1.从领域层开始 三种模式最简单的是事务脚本模式。比较符合大多数人的习惯。它将每种系统事务的逻辑很好的封装在功能完善的脚本中，而且比较适合于在关系数据库之上构建。 它的主要问题是对复杂业务逻辑的支持不够，尤其是不善于处理重复代码。 最复杂的是领域模型模式。缺点是难以学会使用领域模型。第二个缺点就是它与数据库的连接。 表模块模式是这2...

2.远程接口和本地接口 进程内的调用非常快。两个独立的进程间的过程调用就慢了一个数量级。在不同机器间运行的过程又要慢一两个数量级，取决于网络拓扑。 因此，需要远程使用的对象接口应该与就在同一个进程内本地使用的对象接口有所区别。 本地接口最好是细粒度接口。比如，如果一个地址类，则一个好的接口将会有单独的方法，分别用于得到城市，得到州，设置城市，设置州等。 细粒度接口非常好，因为它符合一般...