#微服务

Spring Cloud
我在上一篇对资源服务器进行了简单的阐述，让大家对资源服务器的概念有了简单的认识，今天我将用实际例子来演示单体应用改造为Spring Cloud微服务时的资源服务器实现。 资源服务器改造以Spring Security实战干货的DEMO为例子，原本它是一个单体应用，认证和授权都在一个应用中使用。改造为独立的服务后，原本的认证就要剥离出去（这个后续再讲如何实现），服务将只保留基于用户凭证（JWT）的访问控制功能。接下来我们将一步步来实现该能力。 所需依赖在Spring Security的基础上，我们需要加入新的依赖来支持OAuth2 Resource Server和JWT。我们需要引入下面几个依赖库： <dependency> <groupId>org.springframework.boot</groupId> <artifactI...

架构运维
资源服务器到底是什么以及怎么用很少有教程来专门聊这个东西，今天我们先来聊一聊这个概念，为后续的使用打一打基础。 传统安全方式的不足在Spring Security干货系列教程中，我们一步步来学习了Spring Security的使用。其中大部分涉及到的都是传统的保护应用的方式。我们通过用户名和密码（也可以是验证码）来获得服务器给的凭证（JWT是其中的一种），然后携带凭证去请求接口以获得对应的资源（Resource）。绝大部分的单体应用使用这种模式非常方便和简单。 但是一旦你所在的项目做大了，需要改造成微服务了，使用这种方式就显得有些笨重了，每个服务的资源都需要认证授权，所以需要一种范式来简化这一流程。 认证和授权是可以松耦合的用户的认证和资源的访问控制其实是可以分开的。就比如你买飞机票，现在你不仅可以在航空公司的售票部门买到票，也可以到第三方票务中心线下或者线上去买票，最终每个架次的...

架构运维
为什么选择微服务架构？近几年，微服务架构一直是热点之一，并且被公认为是 IT 软件架构的未来方向。 它是一种灵活的演进式架构，可以提升企业研发效能，同时赋能业务快速创新，目前众多企业应用微服务化，其中包括阿里、Netflix 等。我相信，企业应用微服务化是必然趋势，微服务人才的需求也会越来越高。 微服务架构难？难于上青天？微服务架构落地实施的技术门槛会比较高，它需要基础平台的支撑，包括服务发现，路由，配置，安全和监控等等。这也是现在很多企业面临的困境，有业务微服务改造的需求，但技术人员大都欠缺相关技术经验，无法实施落地。 在我看来，造成这种困惑的主要原因，是缺乏端到端的贴近生产的微服务应用案例。 这里，推荐给你一个叫 Staffjoy 的开源项目，开发了教学版的微服务案例项目。整个项目采用微服务架构，并且可以一键部署到 Kubernetes 容器云环境。 直达 Staffjoy 教学...

架构运维
之前因为在做顾问与咨询的时候，见到了一种关于API网关和注册中心的错误用法。在我的星球里分享了一下这个案例，没想到最近又碰到了两个类似的案例。也许这样的问题还存在不少团队的应用中，所以再拿出来分享一下，希望可以帮助读者更好的理解注册中心与API网关的作用，并将它们用对地方！ 在微服务架构中，我们都会使用API网关来作为暴露服务的唯一出口。这样可以讲与业务无关的各项控制，集中的在API网关中进行统一管理，从而使得业务服务可以更加专注于业务领域本身。 而在微服务构建的系统内部，各个服务之间的调度，我们通常采用注册中心和客户端负载均衡的方式来治理服务之间的调用。 所以，大致的结构是这样子的： 关于注册中心和API网关的功能，主要有以下两点： API网关通过注册中心发现所有后端服务，从来实现动态代理 后端服务集群间，通过注册中心互相发现对方，而实现直接调用 下面就具体说说这个常见的错误...

架构运维
昨晚睡觉前，顺手撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体”，顺藤摸瓜看了一下之前的聊天记录，由于内容骂骂咧咧，我就不贴出来了。。。大致内容就是某公司在做微服务改造，但改的不伦不类，形式上像微服务，而本质上依然是单体，甚至连单体都不如。 这样的改造现象，其实在国内还是蛮多见的。下面就来聊聊这个有趣的话题：分布式单体。各位看官，看看你们公司是不是也犯了这样的错误？ 分布式单体为什么不好先思考一个问题：从单体改造到微服务的时候，你们是不是按这样的步骤来的？ 确定业务领域，拆分存储，定义各微服务的边界 改造代码逻辑，将原来的内部service调用改成dubbo或feign这样的远程调用 通过这样的改造，我们得到了很多好处，比如： 代码库分开了，减少了麻烦的解决代码冲突的困扰 CI/CD分开了，每个拆分后的服务都可以独立开发、部署、运行 数据库分开了，独立运行，不同业务...

架构运维
前言Java微服务能像Go微服务一样快吗？ 这是我最近一直在思索地一个问题。 去年8月份的the Oracle Groundbreakers Tour 2020 LATAM大会上，Mark Nelson和Peter Nagy就对此做过一系列基础的的测试用以比较。接下来就给大家介绍下。 在程序员圈子里，普遍的看法是Java老、慢、无聊 ，而Go是快、新、酷 为了尽可能的进行一个相对公平的测试，他们使用了一个非常简单的微服务，没有外部依赖关系（比如数据库），代码路径非常短（只是操纵字符串），使用了小型的、轻量级的框架（Helidon for Java和Go工具包for Go），试验了不同版本的Java和不同的jvm。 对决双雄我们先来看下擂台两边的选手： 身穿深色战服的选手是JAVA Java是由被甲骨文收购的Sun Microsystems开发的。它的1.0版本是1996年发布的...

Spring Cloud
最近一致在更新Spring Cloud Config的相关内容，主要也是为这篇埋个伏笔，相信不少调研过Spring Cloud Config的用户都会吐槽它的管理能力太弱。因此，就有了下面为讲推荐的这个开源项目，希望对已经入坑Spring Cloud Config的童鞋们有所帮助！ 简介在Spring Cloud的微服务架构方案中虽然提供了Spring Cloud Config来担任配置中心的角色，但是该项目的功能在配置的管理层面还是非常欠缺的。初期我们可以依赖选取的配置存储系统（比如：Gitlab、Github）给我们提供的配置管理界面来操作所有的配置信息，但是这样的管理还是非常粗粒度的，因此这个项目的目的就是解决这个问题，通过此项目，我们将提供一套基于Spring Cloud Config配置中心的可视化管理系统。 在该项目中，我们对于服务治理、配置存储、可视化操作都做了抽象...

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看起来很强大，支持...

Spring Cloud
Swagger Butler是一个基于Swagger与Zuul构建的API文档汇集工具。通过构建一个简单的Spring Boot应用，增加一些配置就能将现有整合了Swagger的Web应用的API文档都汇总到一起，方便查看与测试。 项目地址 Github：https://github.com/dyc87112/swagger-butler Gitee：https://gitee.com/didispace/swagger-butler 使用手册快速入门该工具的时候非常简单，先通过下面几步简单入门： 第一步：构建一个基础的Spring Boot应用 如您还不知道如何创建Spring Boot应用，可以先阅读本篇入门文章 第二步：在pom.xml中引入依赖 <parent> <groupId>org.springframework.boot</gr...

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

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

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

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

架构运维
在这篇文章中将我们一起来探讨当前的API网关的现状和未来。 一. API网关的用处API网关我的分析中会用到以下三种场景。 1.Open API。 企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开放平台、微信开放平台。 Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。 2.微服务网关。 微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。 在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。 3.API...

架构运维
2017年是“微服务”疯狂的一年，如同股灾前的狂欢，各种不同行业的技术团队都在宣讲着自己微服务实践的道路。然而大家是否有反思过自己真的在玩“微服务”吗？您真的在“微服务”中受益了吗？还是为了凑这波的热点，而被折腾的疲惫不堪？ 下面的内容是《The Death of Microservice Madness in 2018》一文的翻译，本文很好地阐述了“微服务”在带来诸多优势的同时也对技术团队增加的复杂度所带来的挑战。各个技术团队Leader们，是时候好好思考一下，在这一波的疯狂中，您的团队是否都做到位了？还是又充当了一回“时髦架构师”？ ——程序猿DD 微服务在过去几年一直是一个非常热门的话题（附录1）。何为“微服务的疯狂”，举个例子： 众所周知，Netflix在DevOps上的表现非常棒。Netfix可以做微服务。因此：如果我做微服务，我也将非常擅长DevOps。 很多情况...