__梦_个人页

风险前置发现和接管。 灰度发布是业界一种规避发布风险的有效手段，常见的做法基本都需要进行灰度环境隔离，不管是硬件隔离还是软件隔离，在实施的时候都代价高昂，维护成本极高，同时因为一些业务的复杂性，因发布导致的故障层出不穷，迫切需要一种简单可行的灰度发布方案。能支持在灰度发布的时候对于即将暴露的风险和问题做提前的发现

1.物理隔离一整套灰度环境，并且承接线上流量，增加灰度流量标识。 2.通过灰度流量的标识单独搭建独立的监控

正确性、性能、健壮性、可扩展性、可靠性、易用性、安全性、兼容性、可移植性等等。 系统设计需要主动而且全面地考虑需求 能否改良算法； 能否改良数据结构； 能否增加缓存； 能否改良硬件设备。

1 使用缓存 2 使用页面静态化 既然不访问数据库逃不过去了，那我们就对数据库进行优化 3 优化数据库（包含的内容非常多，比如参数配置，索引优化，sql优化等等） 4 分离数据库中活跃的数据 5 读写分离 6 批量读取和延迟修改； 7 使用搜索引擎搜索数据库中的数据； 8 使用NoSQL和Hadoop等技术； 9 进行业务的拆分； 10 异步化削峰

IaaS：Infrastructure as a Service（基础设施即服务） 从上面的架构图可以看出，IaaS处于最底层，服务商提供底层/物理层基础设施资源（服务器，数据中心，环境控制，电源，服务器机房），客户自己部署和执行操作系统或应用程序等各种软件。 PaaS：Platform as a Service（平台即服务） PaaS处于中间层，服务商提供基础设施底层服务，提供操作系统（Windows，Linux）、数据库服务器、Web服务器、域控制器和其他中间件，以及服务模型中的备份服务等中件层服务。例如IIS，.NET，Apache，MySQL …，客户自己控制上层的应用程序部署与应用托管的环境。 SaaS：Software as a Service（软件即服务） SaaS处于最上层，服务商提供基于软件的解决方案，满足客户最终需求；如OA、CRM、MIS、ERP、HRM、CM、Office 365、iCloud、G Suite等应用，客户不需考虑任何形式的专业技术知识，获得完整的软件包，使他们的日常工作和生活变得更轻松。 BaaS：Backend as a Service（后端即服务） 服务商为客户(开发者)提供整合云后端的服务，如提供文件存储、数据存储、推送服务、身份验证服务等功能，以帮助开发者快速开发应用。 FaaS：Function as a service（函数即服务） 无服务器计算，当前使用最广泛的是AWS的Lambada。

集群消费模式 适用场景 适用于消费端集群化部署，每条消息只需要被处理一次的场景。此外，由于消费进度在服务端维护，可靠性更高。具体消费示例如下图所示。集群消费 注意事项 集群消费模式下，每一条消息都只会被分发到一台机器上处理。如果需要被集群下的每一台机器都处理，请使用广播模式。 集群消费模式下，不保证每一次失败重投的消息路由到同一台机器上。 广播消费模式 适用场景 适用于消费端集群化部署，每条消息需要被集群下的每个消费者处理的场景。具体消费示例如下图所示。广播消费 注意事项 广播消费模式下不支持顺序消息。 广播消费模式下不支持重置消费位点。 每条消息都需要被相同订阅逻辑的多台机器处理。 消费进度在客户端维护，出现重复消费的概率稍大于集群模式。 广播模式下，消息队列RocketMQ版保证每条消息至少被每台客户端消费一次，但是并不会重投消费失败的消息，因此业务方需要关注消费失败的情况。 广播模式下，客户端每一次重启都会从最新消息消费。客户端在被停止期间发送至服务端的消息将会被自动跳过，请谨慎选择。 广播模式下，每条消息都会被大量的客户端重复处理，因此推荐尽可能使用集群模式。 广播模式下服务端不维护消费进度，所以消息队列RocketMQ版控制台不支持消息堆积查询、消息堆积报警和订阅关系查询功能。

对于微服务架构来说，每个服务都可以单独地管理和部署。比如把服务部署在多个节点上，前端请求过来之后采用负载均衡策略把流量打到具体的机器上。如果某个节点宕机（比如最常见的原因Out of Memory），这时候用户的请求达到了宕机的机器上就会造成很不好的用户体验。又比如说横向扩展的时候，手动添加配置也很繁杂。 服务注册与发现就是用来解决这些问题的。所有服务的IP地址以及端口都存放在一个强一致性的数据中心。对于服务宕机以及添加能够自动发现，不再需要人工干预。

服务提供者、服务消费者、注册中心

各个微服务在启动时，将自己的网络地址等信息注册到注册中心，注册中心存储这些数据。 服务消费者从注册中心查询服务提供者的地址，并通过该地址调用服务提供者的接口。 各个微服务与注册中心使用一定机制（例如心跳）通信。如果注册中心与某微服务长时间无法通信，就会注销该实例。 微服务网络地址发送变化（例如实例增加或IP变动等）时，会重新注册到注册中心。这样，服务消费者就无需人工修改提供者的网络地址了。

可以参考下大神的这篇文章哈 https://lexburner.github.io/dubbo-metadata/

Annotation use @EnableDubboApiDocs: 配制注解, 启用 dubbo api docs 功能 @ApiModule: class annotation, dubbo API module information, used to mark the purpose of an interface class module value: module name apiInterface: Provider implemented interface version: module version @ApiDoc: method annotation, dubbo API information, used to mark the purpose of an dubbo API value: API name description: API description(HTML tags available) version: API version responseClassDescription: response class description @RequestParam: class property/method Parameter annotation, mark request parameters value: parameter name required: true/false required parameter description: parameter description example: parameter example defaultValue: parameter default value allowableValues: Allowed values. After setting this property, a drop-down list will be generated for the parameter Note: a drop-down selection box will be generated after using this property Parameters of boolean type do not need to be set with this property. A drop-down list of true / false will be generated by default Parameters of enumeration type will automatically generate a drop-down list. If you do not want to open all enumeration values, you can set this property separately. @ResponseProperty: Class attribute annotation, mark response parameters value: parameter name example: example

https://github.com/apache/dubbo-spi-extensions/tree/2.7.x/dubbo-api-docs

Dubbo-Api-Docs 是一个展示dubbo接口文档,测试接口的工具. 参考了springfox的设计,通过增加一些描述接口及参数的注解,即可展示具备测试能力的接口文档. Dubbo-Api-Docs 目前通过直连服务节点的方式获取该服务的接口列表. 测试接口时可以直连也可以通过注册中心

使用Swagger，就是把相关的信息存储在它定义的描述文件里面（yml或json格式），再通过维护这个描述文件可以去更新接口文档，以及生成各端代码。而Springfox-swagger,则可以通过扫描代码去生成这个描述文件，连描述文件都不需要再去维护了。所有的信息，都在代码里面了。代码即接口文档，接口文档即代码。

Java原生序列化 只要让类实现 Serializable 接口就行，序列化具体的实现是由ObjectOutputStream和ObjectInputStream来实现的 缺点： 1：序列化码流太大 2：序列化效率低 3：无法跨语言 优点： 1：简单 JSON序列化 JSON 可能是我们最熟悉的一种序列化格式了，JSON 是典型的 Key-Value 方式，没有数据类型，是一种文本型序列化框架，JSON 的具体格式和特性，网上相关的资料非常多，这里就不再介绍了。他在应用上还是很广泛的，无论是前台 Web 用 Ajax 调用、用磁盘存储文本类型的数据，还是基于 HTTP 协议的 RPC 框架通信，都会选择 JSON 格式。 缺点： 1：JSON进行序列化的额外空间开销比较大，对于大数据量服务就意味着需要巨大的内存和磁盘开销 2：JSON没有类型，但像Java这种强类型语言，需要通过反射统一解决，所以性能不会太好 优点： 1：简洁明了 Hessian Hessian 是动态类型、二进制、紧凑的，并且可跨语言移植的一种序列化框架。Hessian 协议要比 JDK、JSON 更加紧凑，性能上要比 JDK、JSON 序列化高效很多，而且生成的字节数也更小 Student student = new Student(); student.setNo(101); student.setName('HESSIAN'); //把student对象转化为byte数组 ByteArrayOutputStream bos = new ByteArrayOutputStream(); Hessian2Output output = new Hessian2Output(bos); output.writeObject(student); output.flushBuffer(); byte[] data = bos.toByteArray(); bos.close(); //把刚才序列化出来的byte数组转化为student对象 ByteArrayInputStream bis = new ByteArrayInputStream(data); Hessian2Input input = new Hessian2Input(bis); Student deStudent = (Student) input.readObject(); input.close(); System.out.println(deStudent);复制代码 缺点： 1：官方版本对Java里面一些常见对象的类型不支持， 比如LinkedHashMap、LinkedHashSet 等，但是可以通过扩展CollectionDeserializer 类修复， Locale 类，可以通过扩展 ContextSerializerFactory 类修复； Byte/Short 反序列化的时候变成 Integer 优点： 1：相对于JDk，JSON，更加高效，生成的字节数更小 2：有非常好的兼容性和稳定性 Protobuf Protobuf 是 Google 公司内部的混合语言数据标准，是一种轻便、高效的结构化数据存储格式，可以用于结构化数据序列化，支持 Java、Python、C++、Go 等语言。Protobuf使用的时候需要定义 IDL（Interface description language），然后使用不同语言的 IDL编译器，生成序列化工具类 缺点： 1：为了提高性能，protobuf采用了二进制格式进行编码。这直接导致了可读性差 2：对于具有反射和动态语言来讲，用起来比较费劲 优点： 1：高效 2：支持多种语言 3：支持向前，向后兼容 Thrift Thrift是Facebook于2007年开发的跨语言的rpc服框架，提供多语言的编译功能，并提供多种服务器工作模式，用户通过Thrift的IDL（接口定义语言）来描述接口函数及数据类型，然后通过Thrift的编译环境生成各种语言类型的接口文件，用户可以根据自己的需要采用不同的语言开发客户端代码和服务器端代码。 缺点： 1：没有官方文档 2：Thrift序列化二进制不可读，调试困难 3：buf fix 和更新不积极，维护成本过高 4：RPC 在 0.6.1 升级到 0.7.0 是不兼容的 优点： 1：特性丰富 2：性能不错 3：有很多开源项目的周边支持 都是 thrift

RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。 RPC 协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。现在业界有很多开源的优秀 RPC 框架，例如 Spring Cloud、Dubbo、Thrift 等。

Client 与 Server 间在收到地址推送后的配置同步是服务自省的关键环节，目前针对元数据同步有两种具体的可选方案，分别是： 内建 MetadataService 独立的元数据中心，通过中细化的元数据集群协调数据

主要的角色：服务提供者（Provider）、服务消费者（Consumer）和注册中心（Registry） 服务提供者启动，首先解析应用定义的“普通服务”并依次注册为 RPC 服务，紧接着注册内建的 MetadataService 服务，最后打开 TCP 监听端口 启动完成后，将实例信息注册到注册中心（仅限 ip、port 等实例相关数据），提供者启动完成 服务消费者启动，首先依据其要“消费的 provider 应用名”到注册中心查询地址列表，并完成订阅（以实现后续地址变更自动通知） 然 消费端拿到地址列表后，紧接着对 MetadataService 发起调用，返回结果中包含了所有应用定义的“普通服务”及其相关配置信息

查看当前服务信息

直接kill就行