微服务

微服务
为什么选择微服务架构？近几年，微服务架构一直是热点之一，并且被公认为是 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年发布的...

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

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

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

微服务
导读：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。 很多情况...

微服务
开篇： 如果在诸多热门云计算技术中，诸如容器、微服务、DevOps、OpenStack 等，找出一个最火的方向，那么非微服务莫属。尽管话题炙手可热，但对传统行业来说，微服务落地和方法论目前处于起步阶段。 本报告于2017年11月份展开，从驱动因素、落地现状、和容器关系、架构体系、未来趋势和落地方法论等方面对微服务进行了分析。希望能够为传统企业微服务决策、规划和实施提供依据和解决办法。 驱动因素传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高，传统架构不堪重负。 微服务架构具有明显的好处，尤其是在应对复杂业务系统的多变需求方面。在本次调研企业中，每个月都要进行业务系统更新的比例占63%，只有不到20%的企业半年以上更新一次系统。 加快互联网+步伐成为许多传统企业的必然选择。业务场景、用户习惯和行为在迅速变化，许多传统行业线上业务出...

微服务
如果在诸多热门云计算技术中，诸如容器、微服务、DevOps等，找出一个最火的方向，那么非微服务莫属。在小数推荐的这篇文章里，做与不做微服务好像理由都很充分。另外，诞生几十年的康威定律，在组织结构调整和变革方面，依然神采奕奕。 创建一种新的软件项目架构，来封装离散服务，对于全新的项目来说，这是非常简单的。但是，对于大多数软件开发者来说，谁又有大把的奢侈时间一直用在全新项目上呢？ 大多数软件开发人员职责更多是维护或增加现有软件系统的功能。但是，如果问开发人员究竟是愿意构建全新的项目，还是维护一个现有的系统，那么支持新项目的呼声肯定会成为压倒性的声音。事实上，希望与新技术或新项目合作也是开发人员离职的原因之一。为什么呢？ 1. 识别问题容易，但修复很难维护现有系统时，很容易识别架构的问题。为什么？因为基于良好的架构，系统很容易调整。 当需要去调整一个没有设计封装波动的已有系统时，架构的...

微服务
虽然之前在《Spring Cloud构建微服务架构》系列文章中介绍了Hystrix服务降级与Hystrix断路器的概念。但是，还是一直收到这样的提问：降级与熔断区别是什么？并且在很多交流过程中，发现有不少童鞋对降级和熔断的概念有混淆的情况。所以，这篇博文准备换一种方式来说说这两个概念，以帮助读者更好的理解之前两篇文章中介绍的这两个重要知识。 下面通过一个日常的故事来说明一下什么是服务降级，什么是熔断。 故事的背景是这样的：由于小强在工作中碰到一些问题，于是想请教一下业界大牛小壮。于是发生了下面的两个场景： 小强在拿起常用手机拨号时发现该手机没有能够拨通，所以就拿出了备用手机拨通了某A的电话，这个过程就叫做降级（主逻辑失败采用备用逻辑的过程）。 由于每次小壮的解释都属于长篇大论，不太容易理解，所以小强每次找小壮沟通的时候都希望通过常用手机来完成，因为该手机有录音功能，这样自己可以慢慢消...