更新于:09-27 17:54

有关[服务]分类推荐

谈Serverless无服务器架构和应用场景(201013)

于10-13 06:44 - 人月神话 - 微服务架构
对于云原生解决方案中涉及到的微服务,DevOps,容器云和ServiceMesh等内容,在前面很多文章都已经谈到过,今天准备谈下对Serverless架构的一些理解. 实际上要完全理解Serverless无服务器架构是一件相对困难的事情,包括到现在我的认知里面仍然认为这种架构是无法满足传统IT应用系统的架构转型和迁移的,只能够应用到一些特定的场景.

4个步骤排查istio服务网格的网络问题

于10-12 11:51 - Kingsluck -
对 istio 用户而言,最常见的场景之一是将 istio 用作 ingress 网关,通过其暴露微服务给外部客户端访问. 一种是只运行业务服务的容器,不携带 sidecar. 另一种是运行携带 sidecar 的 Pod,业务服务和 ingress 网关之间建立 mTLS 双向认证进行通信. 最近,笔者帮一位 istio 用户排查问题:为什么通过 istio ingress 网关暴露的服务不能被 istio 网格外部的 CURL 客户端访问到.

对Kurbernetes中服务暴露方法的一些理解和说明(201001)

于10-01 09:05 - 人月神话 - 微服务架构
由于最近在进一步整理和学习云原生解决方案的相关材料,原来一直没太理解清楚的就是kurbernetes中的网络和服务暴露方式. 在前面谈DevOps解决方案的时候就谈到,一个完整的DevOps持续集成和交付过程,需要和容器云集成,来实现自动化部署,动态弹性伸缩,环境迁移等能力. 一个DevOps支撑平台离不开和容器化PaaS平台的集成,即最终的编译构建完成的内容形成镜像并放到镜像仓库,后续部署,环境迁移,资源扩展基于镜像仓库进行快速的拷贝和复制.

线上服务请求慢问题排查

于09-08 07:35 - 敲代码不如跳舞 -
收到测试的消息,项目页面打开很慢. 查看线上JVM监控平台,发现每分钟由于GC暂停的时间 30~50s. jstat -gccause pid time,发现老年代的占比一直在99%左右,并且发生full gc之后,变化很小. 然后,查看线上gc日志,发现老年代的空间在full gc 前后基本无变化.

Kong 微服务网关在 Kubernetes 的实践

于08-22 00:41 - 灵雀云 -
译者:qianghaohao. 本文主要介绍将 Kong 微服务网关作为 Kubernetes 集群统一入口的最佳实践,之前写过一篇文章使用 Nginx Ingress Controller 作为集群统一的流量入口:使用 Kubernetes Ingress 对外暴露服务,但是相比于 Kong Ingress Controller来说,Kong 支持的功能更加强大,更适合微服务架构:.

微服务下产品集成和集成测试框架流程(200818)

于08-18 18:48 - 人月神话 - 微服务架构
今天谈下微服务架构下的应用集成和集成测试方面的内容. 在微服务架构下,由于传统的的单体应用以及拆分为多个微服务,那么原来单个系统内部的API接口调用以及变成了微服务间的外部接口调用,而且还可能已经由不同的开发团队在开发不同的微服务模块. 在这种情况下如果不能很好的进行产品应用集成和后续集成测试,那么会经常出现类似单元测试问题遗留到集成测试,端到端流程无法测试通过,测试用例和数据反复制作,集成过程中出现问题故障排查困难等诸多问题.

实时数据同步服务如何保证消息的顺序性

于08-16 08:48 - -
上一篇 介绍了移山(数据迁移平台)实时数据同步的整体架构; . 本文主要介绍移山(数据迁移平台)实时数据同步是如何保证消息的顺序性. 这里 查看更多关于大数据平台建设的原创文章. 消息生产端将消息发送给同一个MQ服务器的同一个分区,并且按顺序发送;. 消费消费端按照消息发送的顺序进行消费. 在某些业务功能场景下需要保证消息的发送和接收顺序是一致的,否则会影响数据的使用.

撮合交易系统服务边界与设计_qq_18537055的博客-CSDN博客_activi撮合交易

于08-13 20:32 - -
如何设计并实现一个数字货币交易系统     .         证券交易系统是金融市场上能够提供的最有流动性,效率最高的交易场所. 和传统的商品交易不同的是,证券交易系统提供的买卖标的物是标准的数字化资产,如USD、股票、BTC等,它们的特点是数字计价,可分割买卖.         证券交易系统通过买卖双方各自的报价,按照价格优先、时间优先的顺序,对买卖双方进行撮合,实现每秒成千上万的交易量,可以为市场提供高度的流动性和价格发现机制.

Kubernetes - 集群内容器访问集群外服务

于07-24 13:17 - cheerfun -
GitHub地址: github.com/QingyaFan/c…. 企业内部一般存在很多的微服务,在逐步容器化的过程中,会有部分服务在集群外部,未完成容器化,比如数据库,而部分已经完成容器化的依赖于这些服务的服务,过渡过程中,需要集群内部的容器访问集群外部的服务. 为了在容器化过程中,让服务不中断,就需要让Kubernetes集群内部的容器能访问集群外部的服务,怎么做到呢,在每个应用的配置文件中使用外部IP或者外部rds名字吗.

爱奇艺号基于Prometheus的微服务应用监控实践

于07-25 01:43 - 老马 -
微服务架构是目前各大互联网公司普遍采用的软件架构方式. 在微服务架构中,系统被拆分为多个小的、相互独立的服务,这些服务运行在自己的进程中,可以独立的开发和部署. 在业务快速变化时,微服务单一职责、自治的特点,使系统的边界更加清晰,提升了系统的可维护性;同时,简化了系统部署的复杂度,可以针对某个微服务单独升级和发布;在业务增长时,也可以方便的进行独立扩展.

谈微服务粒度划分(200718)

于07-18 19:36 - 人月神话 - 微服务架构
今天准备谈下在进行企业中台规划或微服务架构设计时候,微服务模块究竟应该如何划分,已经划分的粒度究竟如何才合适. 这个估计是所有人在进行微服务转型的时候都遇到的最典型的例子. 实际上对于微服务模块划分,微服务API接口识别是整个企业中台规划建设方法论中的一个关键内容,我在前面也谈到过当前中台+微服务架构思想实际上仍然可以参考原来的SOA+企业架构咨询的方法进行架构规划,但是对传统方法论本身存在优化和改进.

浅谈微服务体系中的分层设计和领域划分

于07-12 02:29 - 玻璃樽 -
看标题感觉这个东西很理论,比起“高并发、多线程”、“分布式CAP、一致性、Paxos”、“高可用SLA”等具体的干货技术点,软件体系知识显得很“湿”,似乎人人都有自己的认识,但又很少有人能说完整,有一点可以确定的是,如果你未来需要独立设计一个复杂的系统中台,并使之未来能快速应对各种需求变化的话,科学合理的领域划分和边界界定需要我们“处女座级”的坚持下去,这对防止人力失控、减少项目烂尾很有帮助.

微服务的优雅上下线

于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实例,在升级的时候切断其中一台访问,升级完成以后切换流量,再升级另外一台.