eureka

通过前面的学习，使用Spring Cloud实现微服务的架构基本成型，大致是这样的： 我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过Ribbon或Feign实现服务的消费以及均衡负载；通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮，使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。 在该架构中，我们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？ 先来说说这样架构需要做的一些事儿以及存在的不足： 首先，破坏了服务无状态特点。 为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。 从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。 其次，无法直接复用既有接口。 当我们需要对一个即有的集群内访问接口

微服务确实是行业的一个趋势，我自己也在把一些项目往微服务架构迁移。玩微服务架构配置中心是一个绕不过去的东西，有很多大牌的可以选，比如spring-cloud-config，apoll，disconf等等。而我为什么还要造一个轮子呢？一来这些都不是.net实现的，我就想试试用.net core实现一个，而且他们也对.net不太友好，也只有apoll提供了官方的.net客户端。二来这些组件都太重量级了，比如apoll，光跑起来就要部署多个节点（admin,portal,meta sevice）还要依赖eureka。很多旧的项目往微服务迁移的时候并不是一下次全部调整完成的，可能是一步步来的，比如先把所有的服务都容器化，并没有使用微服务全家桶。而且有的项目也不需要微服务全家桶，毕竟微服务不是银弹，很多项目单体结构就足够了，有些项目传统的SOA架构也可以了。（唠叨一句，那种毫无流量毫无并发的项目，几人几天就搞完的强上微服务真的好吗？）但是这些项目也可能是分布式的，容器化部署的，那么这些项目我觉得也是需要配置中心的，因为在分布式、容器化环境下更改配置实在是太麻烦了。可以说配置中心并不是微服务独有的。基于以上原因我提炼了一些配置中心必备的功能，做的尽量简单（陋），开发了AgileConfig，为.net core的生态尽一份绵薄之力。 Github求star： AgileConfig

consul、eureka、nacos对比 配置中心 eureka 不支持 consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新 nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新 注册中心 eureka 依赖：依赖ZooKeeper 应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现， ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。 版本迭代：目前已经不进行升级 集成支持：只支持SpringCloud集成 访问协议：HTTP 雪崩保护：支持雪崩保护 界面：英文界面，不符合国人习惯 上手：容易 consul 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。 版本迭代：目前仍然进行版本迭代 集成支持：支持SpringCloud K8S集成 访问协议：HTTP/DNS 雪崩保护：不支持雪崩保护 界面：英文界面，不符合国人习惯 上手：复杂一点 nacos 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍） 版本迭代

曹工杂谈：分布式事务解决方案之基于本地消息表实现最终一致性 前言 为什么写这个？其实我这边的业务场景，严格来说，不算是典型的分布式事务，需求是这样说的：因为我这边负责的一个服务消费者consumer，是用户登录的入口；正常情况下，登录时候要走用户中心，这是个单独的服务；如果用户中心挂了，我这边自然是没法登录的。 现在的需求就是说，假设用户中心挂了，也要可以正常登录。因为我这个consumer其实也是缓存了用户的数据的，在本地登录也可以的，如果在我本地登录的话，我就得后续等用户中心恢复后，再把相关状态同步过去。 基于这样一个需求，我这边的实现方案是： 1.配置文件里维护一个开关，表示是否开启：故障转移模式。暂不考虑动态修改开关（如果要做，简单做就提供个接口来改；复杂做，就放到配置中心里，我们现在用的nacos，可以改了后推送到服务端） 2.如果开关是打开的，表示需要进行故障转移，则登录、退出登录等各种需要访问用户中心的请求，都存储到数据库中；数据库会有一张表，用来存放这类请求。大致如下： CREATE TABLE `cached_http_req_to_resend` ( `http_req_id` bigint(20) NOT NULL COMMENT '主键', `req_type` tinyint(4) NOT NULL COMMENT '请求类型，1

微服务架构是一个分布式架构，微服务系统按业务划分服务单元，一个微服务系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性较高，如果出现了错误和异常，很难去定位。主要体现在一个请求可能需要调用很多个服务，而内部服务的调用复杂性决定了问题难以定位。所以在微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题能够快速定位的目的。 在微服务系统中，一个来自用户的请求先到达前端A（如前端界面），然后通过远程调用，到达系统的中间件B、C（如负载均衡、网关等），最后到达后端服务D、E，后端经过一系列的业务逻辑计算，最后将数据返回给用户。对于这样一个请求，经历了这么多个服务，怎么样将它的请求过程用数据记录下来呢？这就需要用到服务链路追踪。 Spring Cloud Sleuth Spring Cloud Sleuth 为服务之间调用提供链路追踪。通过 Sleuth 可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长。从而让我们可以很方便的理清各微服务间的调用关系。此外 Sleuth 可以帮助我们： 耗时分析: 通过 Sleuth 可以很方便的了解到每个采样请求的耗时，从而分析出哪些服务调用比较耗时; 可视化错误: 对于程序未捕捉的异常，可以通过集成 Zipkin 服务界面上看到; 链路优化:

前言 在高速发展的时候，公司规模越来越大，老师人数越来越多，这时候公司不能铺太多人去做运营与服务，必须提高每个人效，这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司，如果被迫成为一家靠资金驱动的公司就活不下去了。 -- 张翼（掌门教育创始人兼CEO） 掌门教育自2014年正式转型在线教育以来，秉承“让教育共享智能，让学习高效快乐”的宗旨和愿景，经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ，一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展，特别是今年的疫情，使在线教育成为了新的风口，也给掌门教育新的机遇。 随着业务规模进一步扩大，流量进一步暴增，微服务数目进一步增长，使老的微服务体系所采用的注册中心 Eureka 不堪重负，同时 Spring Cloud 体系已经演进到第二代，第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模，同时它目前被 Spring Cloud 官方置于维护模式，将不再向前发展。如何选择一个更为优秀和适用的注册中心，这个课题就摆在了掌门人的面前。经过对 Alibaba Nacos 、 HashiCorp Consul 等开源注册中心做了深入的调研和比较，最终选定 Alibaba Nacos 做微服务体系 Solar 中的新注册中心。 背景故事 基础架构部选择新的注册中心

线下培训机构如何低成本实现在线知识付费,并拥有自主 独立域名的在线教育系统网站 ，领课在线教育系统支持PC端和移动端小程序播放,可满足各类在线教学需求。 领课教育系统 - 技术说明文档 1. 技术架构图 后台技术说明： 分布式微服务架构 注册中心： Netflix Eureka 配置中心： Spring Cloud Config 服务网关： Netflix Zuul 客服端负载均： Netflix Ribbon 数据库连接池： Alibaba Druid 链路追踪： Spring Cloud Sleuth + Zipkin 应用管理： Spring Boot Admin 文档框架： Swagger 持久层框架： Mybatis 模板引擎： Freemarker 注：列出主要组件，其他组件因太多，不一一列出 前台技术说明： 前后端分离架构 Vue.js： 渐进式技术栈，足以应付任何规模的应用。 Nuxt.js： 服务端渲染，有效地解决单页面应用的 SEO 的问题。 2. 应用架构图 来源： oschina 链接： https://my.oschina.net/u/4386758/blog/4277191

基于API调用行为的二进制通用脱壳方法 注：本人去年参赛的作品，欢迎大家对不足之处提出宝贵的意见，谢谢。 完整图文论文请看我的另一篇博客： https://blog.csdn.net/ITxiaoangzai/article/details/106156192 摘要 加壳技术被广泛应用于恶意代码的自我保护，用于对抗躲避反病毒软件的检测，使得反病毒软件检测率大大降低。所以设计一个能够自动化的通用脱壳系统具有重要的理论和现实意义。 基于上述动机，本文设计和实现了基于API调用行为的二进制通用脱壳系统。本系统利用加壳代码"先重建后调用"的API调用行为特征进行脱壳。整个系统采用B/S架构模式。Browser端负责上传样本到Server端以及向用户反馈分析结果；Server端接收样本后，在沙盒环境中动态运行，通过监控"先重建后调用"的API调用行为特征进行动态脱壳。 本文实现了原型系统VirusMore()。实验结果表明，VirusMore能广泛用于不同的软件壳并进行成功脱壳，提高反病毒软件检测恶意代码的准确率和降低对正常程序的误报率。 第一章 作品概述 1.1 背景分析 伴随着信息技术的不断发展，网络给人们带来便利的同时，网络安全威胁问题也日益突出，网络安全风险不断向政治、经济、文化、社会、生态和国防等各个领域传导渗透。据CNCERT抽样监测，2018年

1.架构图 　　技术团队通过一段时间的积累后，我们打算对往后的一些新项目采用Spring Cloud技术栈来实现。大概微服务的架构如下： Euraka注册中心集群 Zuul网关集群 各模块微服务集群 Nginx实现负载均衡 Spring Cloud Config 统一配置中心 Monitor微服务监控 2.注册中心 　　注册中心很简单，这里主要说一下注册中心的高可用配置‘ 这里看到我设置了node-1，node-2两个配置文件，就是在启动应用的时候，分别启动不同的配置。 node-1的端口为9010，并向node-2注册，配置如下： server: 　　port: 9010 spring: 　　application: 　　　　name: register ##name必须一样，不然高可用会导致unavailable-replicas eureka: 　　instance: 　　　　hostname: register1 　　client: 　　　　register-with-eureka: true 　　　　fetch-registry: true 　　　　service-url: 　　　　　　defaultZone: http://register2:9011/eureka/ node-2的端口为9011，并向node-1注册，配置如下： server: 　　port:

本系列示例与胶水代码地址： https://github.com/HashZhang/spring-cloud-scaffold 入口类注解修改 之前的项目，我们也许会用 @SpringCloudApplication 作为我们入口类的注解。这个注解包括： @SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker public @interface SpringCloudApplication { } 其中的 @EnableDiscoveryClient 会启动服务发现的客户端，我们这里继续用Eureka，但是EurekaClient不需要这个注解，只要加上 spring-cloud-starter-eureka-client 的依赖，就会启动EurekaClient。对于 @EnableCircuitBreaker 这个注解，就比较麻烦了。我们引入了 spring-cloud-starter-netflix-eureka-client 依赖，这个依赖，包含了 hystrix 依赖，导致会自动启用 hystrix 实现 CircuitBreaker 接口，而我们并不想启用hystrix。并且，使用 SpringCloud 的 CircuitBreaker 的抽象接口，并不能完全使用