#转载

Spring Cloud
动态配置管理是 Nacos 的三大功能之一，通过动态配置服务，我们可以在所有环境中以集中和动态的方式管理所有应用程序或服务的配置信息。 动态配置中心可以实现配置更新时无需重新部署应用程序和服务即可使相应的配置信息生效，这极大了增加了系统的运维能力。 动态配置下面我将来和大家一起来了解下 Nacos 的动态配置的能力，看看 Nacos 是如何以简单、优雅、高效的方式管理配置，实现配置的动态变更的。 我们用一个简单的例子来了解下 Nacos 的动态配置的功能。 环境准备首先我们要准备一个 Nacos 的服务端，现在有两种方式获取 Nacos 的服务端： 1.通过源码编译 2.下载 Release 包 两种方法可以获得 Nacos 的可执行程序，下面我用第一种方式通过源码编译一个可执行程序，可能有人会问为啥不直接下载 Release 包，还要自己去编译呢？首先 Release 包也是通...

敏捷管理
在前面我们简单介绍了问题类型和工作流的配置方法，今天我们来聊一聊字段和界面这两个互相依赖的家伙。 界面即Issue展示给用户可见的表单页面，分为创建界面、查看界面和编辑界面。而界面上存在的表单项则称为字段，可以设置这些项是数字、文字、还是图片，以及这些项在界面中是必选、可选，或者是隐藏。 这两个家伙是相互强影响的，因此在这一篇中一起介绍。 * 注：以下配置基于 JIRA 7.1.9 字段我们已经知道如何在项目中建立问题类型和设置这些问题类型的工作流，但是这些问题的状态和内容如何清晰的展示给用户呢？ 比如创建问题的时候，界面需要展示哪些内容来明确标识问题的相关信息？选择问题类型之后，如何表述问题的具体内容？所属模块、解决版本等信息都在哪体现呢？这些都需要通过界面和字段进行定义。 当我们创建界面时，需要规定这个界面上显示给用户可见的字段信息，这些字段信息需要预先进行定义。 1.1 创...

敏捷管理
在项目管理中Jira占据着大佬的地位，很大部分原因要归功于他强大的工作流支持，你可以完全根据自己的企业和团队习惯自定义工作流内容，包括步骤、流转、条件和权限等等。 今天我们就来看看Jira工作流要如何配置吧。 * 注：以下配置基于 JIRA 7.1.9 工作流在上一篇文章中，我们新建了一个问题类型，并且增加到问题类型方案里了，同时又关联到我们的这个项目中。那么这些问题我们需要如何设置流程走向来表示问题的处理过程呢？这就需要设定一个流程，并将这个流程引用到这个问题类型中。 1.1 新建工作流具有系统管理权限的人员登录进入问题管理中，在左导航中选择工作流。 我们可点击增加工作流，在弹出的对话框中，输入名称，点击增加按钮即可 点击增加按钮后跳转到工作流详细设计界面。 我们这里先简单的介绍如何创建工作流，由于不同的使用场景工作流的配置也会不同，内容较多，设计的场景也各有式各样。 我们先...

敏捷管理
最近在工作中频繁接触Jira，从一脸懵逼的小白摸索成为一个准管理员，爬了不少坑，特此整理如下，望有助于在座各位~ * 注：以下配置基于 JIRA 7.1.9 项目管理新建项目后首先需要配置的内容包括：问题类型方案、工作流配置方案、字段配置方案、问题类型界面方案，一般完成这四个配置项目即可使用，如果还需要其它的，可以继续配置这个项目的权限、问题安全方案、通知方案等，还包括其它管理内容，如模块、项目角色。 这里先说明问题类型方案、工作流配置方案、字段配置方案、问题类型界面方案的配置规范。 下面是项目和问题类型、界面、工作流、字段之间的相互关系图： 1.1 创建项目一个项目是对一系列相关问题的综合管理。在Jira 中，可以通过以下方式创建项目。首先，需要具有项目创建权限的人登录后台管理界面，然后选择项目，通过创建项目按钮进入到项目创建的界面。 进入到项目管理界...

Spring Cloud
介绍在今年5月中，Netflix终于开源了它的支持异步调用模式的Zuul网关2.0版本，真可谓千呼万唤始出来。从Netflix的官方博文[附录1]中，我们获得的信息也比较令人振奋： The Cloud Gateway team at Netflix runs and operates more than 80 clusters of Zuul 2, sending traffic to about 100 (and growing) backend service clusters which amounts to more than 1 million requests per second. Netflix部署了超过80+的Zuul2云网关集群，流量经过Zuul2集群被路由到后端超过100+的微服务，且每秒钟经过Zuul2集群的请求超过100万。 Zuul2看起来很强大，支持...

架构运维
随着微服务架构风格的流行，组织内部不可避免的产生了许多小规模团队，原来一个几十上百人的产品团队被拆分成了类似Amazon这样的2 pizza（6~10人）小团队。组织结构上也由之前的层级化职能团队设置变成了扁平的小团队集群。每个做这样调整的企业都希望借助小团队的灵活性在这个科技时代跟上市场变化和创新的脚步。 当然这样的组织方式本身就带来了一系列的挑战，技术实践方面Martin Fowler已经通过微服务的定义文章做了很形象的叙述，还用了“你必须长这么高”（You must be this tall！）来比喻在技术实践方面所需做出的投入。 在组织管理方面，越来越多的挑战被识别出来，把“自组织”当做银弹来回答这样集群小团队组织和管理中的问题是行业里存在的一个不好趋势。在最近和Matin Fowler的讨论中，我们达成共识的一点是：与其说微服务是一种技术架构，还不如说是一种企业组织架构。...

架构运维
最近经常在项目或是社区里听到大家谈论微服务架构，但谈论的焦点更多集中在微服务拆分，分布式架构，微服务门槛，DevOps配套设施等话题上。 但是在我眼里，真正能称之为微服务架构的少之又少。原因也很简单，我所见到的很多所谓的微服务架构项目，大多都没有做到微服务架构的一个基本要求：服务的独立部署（交付）。 这里的独立部署和自动化部署还不是一个概念，服务的自动化部署相对简单，已有大量的工具可以帮助我们做到。但是这里所谈的独立部署，我认为关键和难点并不在于“部署”，而在于“独立”。 如果失去了服务独立部署（交付）的能力，一个微服务架构的威力将大打折扣，我们的系统虽然在物理上被拆分成了多个小的服务，但是如果从最终交付的角度来看，仍然是以一个整体存在的，就像单体应用一样，存在诸多的问题。 为什么服务的独立交付并不简单？那为什么不能让每一个服务都独立部署到产品环境呢？问题的答案是：不是不能，而是不...

Spring Cloud
前言上篇文章《Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失》我们对ThreadLocal数据丢失进行了详细的分析，并通过代码的方式复现了这个问题。 在上篇文章的末尾我也说了思路给大家提供了，如果需要能够在Hystrix 为线程隔离模式也能正确传递数据的话，需要我们自己去修改。 我这边以Zuul中自定义负载均衡策略来进行讲解，在Zuul中需要实现灰度发布的功能，需要在Filter中将请求的用户信息传递到自定的负载策略中，Zuul中整合了Hystrix，从Zuul Filter的请求到Ribbon的策略类中，线程已经发生了变化，变成了Hystrix提供的线程池来执行（配置隔离模式为线程）。这个时用ThreadLocal就会出问题了，数据传输会错乱。也就是我们前面分析的问题。 关于修改我说下自己分析问题的一些思路，ransmittable-threa...

架构运维
阅读对象传统企业正在做微服务架构转型的开发人员或者架构师，希望本文对您能起到一定的引导作用。 API网关介绍网关一词较早出现在网络设备里面，比如两个相互独立的局域网段之间通过路由器或者桥接设备进行通信， 这中间的路由或者桥接设备我们称之为网关。 相应的API网关将各系统对外暴露的服务聚合起来，所有要调用这些服务的系统都需要通过API网关进行访问，基于这种方式网关可以对API进行统一管控，例如：认证、鉴权、流量控制、协议转换、监控等等。 API网关的流行得益于近几年微服务架构的兴起，原本一个庞大的业务系统被拆分成许多粒度更小的系统进行独立部署和维护，这种模式势必会带来更多的跨系统交互，企业API的规模也会成倍增加，API网关（或者微服务网关）就逐渐成为了微服务架构的标配组件。 如下是我们整理的API网关的几种典型应用场景： 1、面向Web或者移动App 这类场景，在物理形态上类似前后...

Spring Cloud
在Spring Cloud中我们用Hystrix来实现断路器，Zuul中默认是用信号量（Hystrix默认是线程）来进行隔离的，我们可以通过配置使用线程方式隔离。 在使用线程隔离的时候，有个问题是必须要解决的，那就是在某些业务场景下通过ThreadLocal来在线程里传递数据，用信号量是没问题的，从请求进来，但后续的流程都是通一个线程。 当隔离模式为线程时，Hystrix会将请求放入Hystrix的线程池中去执行，这个时候某个请求就有A线程变成B线程了，ThreadLocal必然消失了。 下面我们通过一个简单的列子来模拟下这个流程： public class CustomThreadLocal { static ThreadLocal<String> threadLocal = new ThreadLocal<>(); public st...

架构运维
导读：Uber成长非常迅速，工程师团队快速扩充，据说Uber有2000名工程师，8000个代码仓库，部署了1000多个微服务。微服务架构是Uber应对技术团队快速增长，功能快速上线很出色的解决方案。本文偏向微服务的入门篇，以Uber微服务为例，进行了深入浅出的讲解。 微服务特性对于微服务没有适当的定义，你可以说它是一个框架，由小型的、独立的可部署的服务组成，执行不同的操作。 微服务专注于单个业务领域，可以作为完全独立的可部署服务，并在不同的技术栈上实现它们。 在使用微服务构建自己的应用程序之前，需要清楚地了解应用程序的范围和功能。 解耦 - 系统内的服务在很大程度上是解耦的。因此，整个应用程序可以轻松构建，更改和缩放 组件化 - 微服务被视为独立的组件，可以轻松替换和升级 业务能力 - 微服务非常简单，专注于单一功能 自治 - 开发人员和团队可以独立工作，从而提高速度 持续...

架构运维
技术雷达：现在越来越多的大型组织在向更加自组织的团队结构转型，这些团队拥有并运营自己的微服务，但他们如何在不依赖集中式托管的基础架构下，确保服务之间必要的一致性与兼容性呢？为了确保服务之间的有效协作，即使是自组织的微服务也需要与一些组织标准对齐。服务啮合(SERVICE MESH)在服务发现、安全、跟踪、监控与故障处理方面提供了一致性，且不需要像API网关或ESB这样的共享资产。服务啮合的一个典型实现包含轻量级反向代理进程，这些进程可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通信。通过该代理的共享实现（而非共享的运行时实例），我们可以获得服务的互操作性和可观测性。一段时间以来，我们一直主张去中心化的微服务管理方法，也很高兴看到服务啮合这种一致性模式的出现。随着linkerd和Istio等开源项目的成熟，服务啮合的实现将更加容易。...