更新于:10-11 15:31

有关[服务]分类推荐

微服务的优雅上下线

于07-02 13:29 - 大卫 -
对于微服务来说,服务的优雅上下线是必要的. 就上线来说,如果组件或者容器没有启动成功,就不应该对外暴露服务,对于下线来说,如果机器已经停机了,就应该保证服务已下线,如此可避免上游流量进入不健康的机器. 基础下线(Spring/SpringBoot/内置容器). 首先JVM本身是支持通过shutdownHook的方式优雅停机的.

爱奇艺微服务监控的探索与实践

于06-14 02:03 - 老马 -
作为一线程序猿,是否有过类似经历. 新接手一个系统,各接口入口流量是多少,又是哪些业务方在调用. 系统大量异常报警,如何快速锁定影响范围,恢复故障并定位问题. 监控的重要性不言而喻,可是接入监控的额外工作又让人望而却步. 每天编写代码之余,又要花多少时间定位线上问题. 自己负责的系统故障,是否要等调用方反馈才知道.

爱奇艺视频后台从“单兵作战”到“团队协作”的微服务实践

于06-13 16:54 - 大卫 -
系统越做越大,功能越加越多,我们是否有如下经历:. 一次小的需求,评估由此产生的影响成本超过开发需求本身. 系统几经交接或升级,接口文档丢失或跟代码严重不符. 每天疲于排查线上问题和修复线上数据,没有精力代码优化. 由于创建/开发/部署新服务的成本,不断的将无关的功能添加到臃肿的服务. 线上服务一个功能或者中间件的中断,导致整个系统不能提供服务.

在云服务器部署redis集群遇到的问题 - 简书

于06-03 10:59 - -
具体环境:两台云端服务器 专有网络. 软件环境: jedis 2.9.0 redis3.2.10. 1、先是设置了redis密码再集群,见. /usr/lib/ruby/gems/1.8/gems/redis-3.3.0/lib/redis/client.rb这里的. client.rb文件路径是按照你安装ruby、在通过gems安装redis3.3的时候的路径(不熟悉ruby的软件安装).

微服务的合适大小

于06-01 01:15 - 新牛哥 -
【编者的话】本文通过一个简单例子,挑战了一个广泛传播的误区:一个微服务正好等于一个REST接口. 并以此为契机,指出应该按照业务领域而非技术领域进行团队组织,根据领域驱动设计理念,利用业务词汇,分别从下限和上限判断微服务规模大小. 同时建议团队在了解并成功实现了敏捷方法和DevOps原则的基础上,才能尝试大规模采用微服务.

Netflix基于云的微服务架构的设计分析

于05-25 23:31 - frankinbj -
Netflix的微服务架构为其提供全球视频流服务,本篇文章将对此架构进行全面的系统设计分析. Netflix多年来一直是全球最出色的在线订阅制的视频流服务( 【12】 )之一,其占世界互联网带宽容量的15%以上. 2019年,Netflix已经获得了超过1.67亿的订阅用户,每个季度新增用户超过500万,服务涵覆盖全球200多个国家或地区.

Kubernetes在微服务中的最佳实践

于05-24 01:59 - cainzhong -
你可以在网上找到许多关于如何正确构建微服务体系架构的最佳实践. 其中之一是我以前写的一篇文章 Spring Boot在微服务中的最佳实践. 我把重点放在在生产上基于Spring Boot构建的微服务应用程序应该考虑哪些方面. 我没有使用任何用于编排或管理应用程序的平台,而只是一组独立的应用程序. 在本文中,我将基于已经介绍的最佳实践,在Kubernetes平台上部署微服务,你需要注意的一些新规则和事项.

设计一个成功微服务的9个基本要素

于05-23 13:51 - 阿娇 -
人体是不同系统的组合,其中大多数系统是独立的,并且作为一个整体协同工作. 所有具有多种其他支持框架的器官构成了一个功能完备的机构. 现在,如果应用于软件系统,这就是微服务架构的概念. 在技术方面,微服务系统允许开发单个功能模块. 这种开发单一功能模块的趋势为大型和小型组织提高了灵活性,性能和成本效率,同时实现了持续测试和早期交付.

Spring Boot在微服务中的最佳实践

于05-17 23:18 - cainzhong -
在本文中,我将列出构建Spring Boot应用程序的“金科玉律”,这些应用程序是微服务系统一部分. 这些“金科玉律”都来自我过往的经验,我曾经将运行在JEE服务器上的单体SOAP应用程序迁往基于REST的小型Spring Boot应用程序. 这些最佳实践假设你的产品上已经拥有许多微服务,且每天要应对海量的请求.

微服务全链路跟踪:jaeger集成istio,并兼容uber-trace-id与b3 - lipeng的个人空间 - OSCHINA

于05-03 08:20 - -
微服务全链路跟踪:grpc集成zipkin. 微服务全链路跟踪:grpc集成jaeger. 微服务全链路跟踪:springcloud集成jaeger. 微服务全链路跟踪:jaeger集成istio,并兼容uber-trace-id与b3. 微服务全链路跟踪:jaeger集成hystrix. 公司有自己的一套基于k8s的paas系统,并且集成了istio,这里主要是想讲解下springcloud服务如何集成istio.

Uber 一团队正从微服务转向宏服务-InfoQ

于04-20 14:22 - -
也许在某个丛林深处的某个地方,有一个未被发现的部落还没有对微服务下定决心,但我很怀疑这一说法. 因为人们对微服务的态度是非爱即恨. 这两者之间并没有什么太多的中间地带. 所以,当 Uber 这样的公司的一支团队宣布从微服务转向其他东西时,这意味着什么. 想想看,你对 Uber 这家公司是怎么看的. 但从软件的角度来看,Uber 一直是个“好公民”.

你应该更谨慎的采用微服务

于04-12 23:42 - grace_shi -
(微服务)不就是写一堆小的程序么. 某一天,你正在寻找一种新的方式来重构整个代码库. 您考虑过使用一种新的语言,或者在另一个云服务商上进行部署,又或者是使用一种更好的编程模式. 突然,你发现你可以同时实现这三种方式. 对于初学者来说,“微服务”是一种架构模式,其中,一个应用程序是由多个松散耦合的服务组成,这些服务都可以独立部署.

从0开始部署Rancher2.0到微服务容器部署与持续集成 | tEngSHe789の小站

于04-05 21:42 - -
Rancher是一个开源的企业级容器管理平台. 通过Rancher,企业再也不必自己使用一系列的开源软件去从头搭建容器服务平台. Rancher提供了在生产环境中使用的管理Docker和Kubernetes的全栈化容器部署与管理平台. 今天分享一下我从0开始部署Rancher2.0到微服务容器部署与持续集成的历程.

一个成功的程序员,自然要懂微服务,汇总微服务架构的15钟框架!

于03-10 14:30 - 风平浪静如码 -
这几年来,微服务这个概念越来越火了,火到什么程度呢. 2019年有一个统计说,两千家企业里,45%在使用微服务,16%在实验开发和测试微服务架构,24%在学习微服务准备转型,只有剩下的15%的企业没有使用微服务. 微服务在2013年才被提出,短短几年就有这么快速的发展. 微服务架构能够实现由小型自主服务组成一个整体应用,各个组成部分之间是松耦合的,复杂性低,各个部分可以独立部署,修复bug或者引入新特性更容易,能够独立扩展,不同技术栈之间可以使用不同框架、不同版本库甚至不同的操作系统平台.

使用 Kubernetes Ingress 对外暴露服务

于03-07 02:16 - 老马 -
本文主要介绍如何通过 Kubernetes Ingress 资源对象实现从外部对 Kubernetes 集群中服务的访问,介绍了 Kubernetes 对外暴露服务的多种方法、Ingress 及 Ingress Controller 的概念. Kubernetes 对外暴露服务的方法. 向 Kubernetes 集群外部暴露服务的方式有三种: nodePort,LoadBalancer 和本文要介绍的 Ingress.

说说Kubernetes是怎么实现服务发现的

于02-24 03:04 - fredal -
我们来说说 kubernetes 的服务发现. 那么首先这个大前提是同主机通信以及跨主机通信都是 ok 的,即同一 kubernetes 集群中各个 pod 都是互通的. 这点是由更底层的方案实现,包括 docker0/CNI 网桥、flannel vxlan/host-gw 模式等,在此篇就不展开讲了.

基于kong的微服务解决方案 | kong

于02-16 12:12 - -
最近处理了几个客户的需求,需求有相似之处,解决方案迭代几次以后也具备了一定的复制性. 目前应用用springboot写的,以业务分块,大概形成了几十个(30+)部署单元;每个部署单元都是独立的jar,其中每个包含十个左右的endpoints. 目前用了eureka和zuul做服务注册/发现以及负载均衡;在整体部署规模超过200个jvm之后,出现了一些问题.

Spring Cloud 不停机发布服务(0-downtime Blue/Green deployments) | 帆的博客

于02-15 22:51 - -
项目初期由于BUG和需求改动可能都会比较多,我们会很频繁的发布我们的应用. 但是如果不进行处理,在升级的过程中会导致用户服务中断. 实际上针对这两种情况,在传统的应用中我们是很容易做到不停机升级的. 例如nginx负载均衡2台tomcat实例,在升级的时候切断其中一台访问,升级完成以后切换流量,再升级另外一台.

SpringCloud灰度发布实践(附源码) - 微服务实践 - SegmentFault 思否

于02-15 17:47 - -
在平时的业务开发过程中,后端服务与服务之间的调用往往通过. resttemplate两种方式. 但是我们在调用服务的时候往往只需要写服务名就可以做到路由到具体的服务,这其中的原理相比大家都知道是. ribbon组件帮我们做了负载均衡的功能. 灰度的核心就是路由,如果我们能够重写ribbon默认的负载均衡算法是不是就意味着我们能够控制服务的转发呢.

微服务架构:如何用十步解耦你的系统?

于02-14 14:04 - 风平浪静如码 -
耦合性,是对模块间关联程度的度量. 耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少. 模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系. 模块间联系越多,其耦合性越强,同时表明其独立性越差. 软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准.

大规模微服务场景下灰度发布与流量染色实践

于02-13 02:40 - Andy_Lee -
最近微服务很热,与微服务相关的架构、流程、DevOps都很热. 很多公司,包括传统企业,到互联网公司做交流的时候,会问道,你们互联网公司号称能够加速业务创新、快速迭代,那我们是否也可以引入类似这样的机制. 我们做微服务,主要分为两个方面,一个是业务方面,另一个是技术方面. 最下面是运维部,不过现在我们的运维部已经拓展成云计算,DBA里的数据管理部门,已经发展成大数据,于是就有了技术中台和数据中台,另外还有共享用户中心的业务中台,总体构成了下层的中台部门,在上层业务一定要做微服务化.

JHipster生成微服务架构的应用栈(一)- 准备工作 - 羽客 - 博客园

于02-11 15:10 - -
本系列文章演示如何用JHipster生成一个微服务架构风格的应用栈. 环境需求:安装好JHipster开发环境的CentOS 7.4(. 业务微服务:microservice1. 主机IP:192.168.220.120. 本系列文章会说明如何生成uaa(即图中的JHipster UAA),microservice1,gateway这3个微服务.

为什么在做微服务设计的时候需要DDD?

于02-02 22:56 - JetLee -
记得之前在规划和设计微服务架构的时候,张队长给了我一个至今依然记忆深刻的提示:『你的设计蓝图里为什么没有看到DDD的影子呢. 随着对充血模型的领域认知的加深,我越加感觉到DDD的重要性. 但是DDD内容繁多,是不是要深入去了解呢,我觉得不必入坑太深,个人浅见,它最核心的一点就是针对贫血模型的不足而设计,把原先传统的贫血模型里的业务逻辑层拎出来,融入到Domain层,这样面对复杂业务的规模化变更,我们只需要专注于Domain即可.

一文讲透微服务架构下如何保证事务的一致性

于01-07 18:25 - 梁桂钊 -
随着业务的快速发展、业务复杂度越来越高,传统单体应用逐渐暴露出了一些问题,例如开发效率低、可维护性差、架构扩展性差、部署不灵活、健壮性差等等. 而微服务架构是将单个服务拆分成一系列小服务,且这些小服务都拥有独立的进程,彼此独立,很好地解决了传统单体应用的上述问题,但是在微服务架构下如何保证事务的一致性呢.

微服务划分的姿势

于01-06 23:16 - JetLee -
【编者的话】我们知道微服务是一种理念,没有确切的定义和边界,好比设计原则,是属于抽象的概念. 在定义不明确的情况下谈划分也是一种各说各话,具体问题需要具体分析,所以这篇文章谈到的划分也不是绝对标准,仅供参考. 有人说微服务不难,难的是服务的划分,虽然我持保留意见,但是从侧面也反应了划分具有一定的困难.

漏洞非小事,金融服务机构如何对抗代码缺陷?

于01-01 15:00 - RIodian - 观点 金融安全 金融机构
在全球金融行业数字化转型与升级的大趋势下,不论是传统银行业的联网业务和手机银行业务,还是移动支付、P2P金融乃至数字货币和区块链,金融行业新技术和新应用层出不穷,银行业、证券业、保险业纷纷都开始依赖应用软件进行业务的拓展及维护. 面对日益激烈的商业竞争,市场不等待,也要求开发者缩短开发和创新的时间.

微服务和DevOps和容器关系(12.28)

于12-28 10:04 - 人月神话 - 微服务架构
前面自己写过很多微服务,DevOps,容器化PaaS平台方面的文章,今天再梳理下几者之间的关系问题. 首先看下微服务,我们把微服务里面的一些关键组件拆分出来,其中包括了注册中心,配置中心,网关,限流熔断,服务链监控,可以看到这些组件都是可以独立的关键组件. 其次我们看下DevOps平台,在我原来的介绍里面也可以看到,我们将DevOps平台做为一个大的支撑平台,但是拆分后可以看到里面包括了敏捷研发管理,持续集成,容器化PaaS,测试平台等几个关键内容.

谈SkyWalking进行服务链监控(12.27)

于12-27 08:10 - 人月神话 - 微服务架构
在谈Nacos服务注册的时候,刚好看到了Skywalking分布式追踪系统,而这个本身也完全可以用于微服务架构里面的服务链监控上面. 对于APM应用性能监控工具有很多,常说的主要是类似Zipkin, Pinpoint, Cat等,而Skywalking是国产的一款开源APM工具软件,包括了包括了分布式追踪、性能指标分析、应用和服务依赖分析等.

高并发、高可用架构系列(一):手把手带你构建大规模分布式服务

于12-21 00:00 - - dev
阅读本(系列)文章,你将会收获:. 全面、体系化的了解大规模分布式系统中的服务治理  . 一线互联网公司如何应对高并发、大流量场景,稳定性保障体系揭秘(高并发高可用必备)  . 常见限流算法的实现,阿里巴巴(历年双十一)限流、熔断保护利器sentinel的设计原理和实践经验(高并发高可用必备)  .

使用Consul实现服务发现:instance-id自定义

于12-19 14:18 - - Spring Cloud Spring Cloud Spring Cloud Consul Consul
本文基于Spring Cloud Hoxton,理论支持Spring Cloud所有版本. 本文探讨如何自定义微服务注册到Consul的InstanceId. Consul把InstanceId作为唯一标识,而Spring Cloud Consul默认的InstanceId是 ${spring.application.name}-${server.port}.