更新于:04-06 09:44

有关[服务]分类推荐

微服务转型的三大误区,避坑指南→

于04-17 02:41 - 博云BoCloud -
通常企业的数字化转型和系统的微服务化改造很容易被放在一起讨论,这样的说法是把微服务放到了一个系统级别,也就成为了一个部门或一个团队的任务. 这其实就是一个企业刚开始做微服务转型的最大误区. 微服务化转型是企业级的改造工程,而具体的落实才是系统的改造,只关注于系统的微服务化改造,难免会“守一隅而遗万方”.

避免微服务的误解

于04-13 20:39 - Zangying2005 -
开篇声明:我是微服务的超级粉丝. 当下的时代,每隔一段时间就会出现一种新概念或新技术,它带来了希望、炒作的热点,貌似可以拯救全世界一样. 但我认为,这确实有它正确的一面,新技术具备突破性,能够带来重大受益. 然而,它也像生活中的其他任何事物一样,有它的能力适用范围. 就好比我们不能把牛顿定律应用到亚原子粒子上面,或者尝试过把电视塞进袜子里.

网易云信在融合通信场景下的探索和实践之 RTMPGateway 服务架构

于04-08 08:16 - 网易云信 -
随着各个行业的互联网化进程不断演进,融合通信在越来越多的场景中得到应用,例如金融场景的视频面签、医疗场景的远程会诊、企业协作场景的多人视频会议等. 在这些场景中,通过微信小程序实现音视频互通,可以降低用户沟通成本,提升业务运营效率,同时帮助企业或组织进一步打通微信社群中的沟通障碍,以一种轻量化的敏捷运营模式轻松实现微信生态中的客户转化闭环.

服务端如何防止重复支付?

于04-01 01:58 - Java小咖秀 -
作者:废物大师兄, 链接:. 如图是一个简化的下单流程,首先是提交订单,然后是支付. 支付的话,一般是走支付网关(支付中心),然后支付中心与第三方支付渠道(微信、支付宝、银联)交互,支付成功以后,异步通知支付中心,支付中心更新自身支. 如图是一个简化的下单流程,首先是提交订单,然后是支付. 支付的话,一般是走支付网关(支付中心),然后支付中心与第三方支付渠道(微信、支付宝、银联)交互,支付成功以后,异步通知支付中心,支付中心更新自身支付订单状态,再通知业务应用,各业务再更新各自订单状态.

SaaS成功,需要四种运营服务_阿朱=行业趋势+开发管理+架构-CSDN博客

于03-08 06:07 - -
2015年,我做过一次外部演讲,我讲的内容是:SaaS不仅需要运维,更需要运营. 一提起运营,互联网人想到的是:拉新(下载/注册)、留存(内容运营)、活跃(社区运营). 一提起SaaS运营,SaaS厂商就想到了客户成功运营,想到了客户运营老做的几个事:用户开通/用户使用情况监控、培训学习社区运营、支持社区运营.

微服务架构从理想到现实

于02-28 08:29 - 玻璃樽 -
【编者的话】本文为我最近阅读《微服务架构设计模式》的一点感悟,我不准备详细去写对该书的读书笔记记录,而是结合我们自己所做的一些微服务架构实践情况做一些总结和复盘. 任何一个新的架构模式或方法的出现,一定是传统架构模式遇到了问题. 而对于单体应用来说常说的问题主要包括了如下几个点:. 单体应用规模太大,导致复杂度剧增,难以开发和管理.

审视微服务架构:影响因素、运维复杂性和替代方案 |InfoQ 圆桌

于02-16 22:07 - Wesley Reisz,Yan Cui -
本文要点:尽管业界已有一些迁移到微服务的成功案例,但依然有大量企业尚未接触到微服务战略. 当前的微服务方式比以往都要复杂. 我们正构建越来越复杂的系统,使用越来越复杂的架构,进而导致我们举步维艰,学习曲线陡峭.  除了复杂性之外,如何监控和追踪也是微服务面对的极大挑战.  事件驱动架构是构建微服务的很好方法,尤其是针对各服务间的通信.

微服务实现简单的分布式日志追踪

于01-25 00:32 - aoxiang -
最近想给项目添加一个简单的分布式请求跟踪功能,从前端发起请求到网关,再从网关调用 Spring Cloud 的微服务,这些过程中希望能从日志中看到一个分布式 ID 的链路,通过请求的 ID 可以追踪整一条链路,方便问题的排查. 现成的方案自然是使用 SkyWalking 、 Spring Cloud Sleuth 、Zipkin 之类的组件,但是想到主要的目的记录一个可以一直贯通各个服务的 ID,方便日志查询,也就不想引入太多复杂的组件,最终决定通过 MDC 在日志中输出追踪的 ID,然后在 Feign 和 RestTemplate 中将请求 ID 在微服务中传递.

微服务架构统一安全认证设计与实践

于01-19 10:56 - 老马 -
【编者的话】当企业应用系统逐渐增多后,每个系统单独管理各自的用户数据容易形成信息孤岛,分散的用户管理模式阻碍了企业应用向平台化演进. 当企业的互联网业务发展到一定规模,构建统一的标准化账户管理体系将是必不可少的,因为它是企业互联网云平台的重要基础设施,能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力,为企业带来诸如跨系统单点登录、第三方授权登录等基础能力,为构建开放平台和业务生态提供了必要条件.

企业中台规划和IT架构微服务转型杂谈

于01-16 21:26 - 人月神话 -
对于传统企业IT架构转型,中台和微服务架构规划在我头条前面的文章里面都有比较系统的整理和阐述,虽然云原生概念在2013年就提出,但是2020年可以算作是云原生的元年,同时企业IT架构转型,微服务化和逐步迁移上公有云也将是未来多年的一个技术发展趋势. 最近结合和合作伙伴,客户的沟通交流,对一些常用的问题进行整理和说明.

这些 Shell 分析服务器日志命令集锦,收藏好了~

于01-05 00:00 - - tuicool
自己的小网站跑在阿里云的 ECS 上面, 偶尔也去分析分析自己网站服务器日志,看看网站的访问量. 于是收集,整理一些服务器日志分析命令,大家可以试试. 1、查看有多少个IP访问:. 2、查看某一个页面被访问的次数:. 3、查看每一个IP访问了多少个页面:. awk '{++S[$1]} END {for (a in S) print a,S[a]}' log_file > log.txt sort -n -t ' ' -k 2 log.txt 配合sort进一步排序.

微服务架构下你的数据一致了吗?

于12-30 00:00 - - dev
数据一致性问题首先是个业务问题,其次才是个技术问题. 在微服务架构下,我们期望每个服务职责单一,这种职责单一体现的是业务价值,如果微服务的拆分过小而导致业务难以实现,那这种拆分是不合理的,业务专家们非常有必要了解系统,从业务侧给出服务拆分的建议. 微服务架构的流行源于它能够带来更快的变化响应能力,比如独立部署,每个服务的能力职责是独立的,可以按需独立发布;再比如每个服务可以由不同的开发团队负责,每个服务的技术栈也可以不同,可以选择更快捷合理的方式实现不同的服务.

中台和微服务架构规划-模块划分和接口服务识别定义(201123)

于11-23 08:12 - 人月神话 - 微服务架构
对于传统企业微服务架构转型,基于中台和微服务思想进行传统IT系统的改造和优化是一个重要的趋势,特别是在企业IT架构逐步走向云原生技术的时候,微服务本身也是关键的要素. 而对于微服务整体的治理框架,我在前面给出一个大的框架图,如下:. 整个微服务治理框架覆盖了微服务全生命周期管理,其中本身又分为微服务架构规划和微服务开发和运维两个关键的阶段.

业务和流程驱动的SOA服务识别方法总结(201223)

于12-23 21:14 - 人月神话 - 微服务架构
今天整理和分享下流程驱动的SOA服务识别方法,该方法在传统SOA架构规划咨询中应用比较多,对于当前的微服务架构规划咨询仍然可以参考借鉴. 服务识别和服务需求分析的主要工作是基于SOA的需求分析方法论,以流程和业务驱动IT的指导思想,对业务系统进行业务建模,用例建模和业务实体建模,形成企业级需求和业务功能清单,作为后续服务识别的输入.

React服务端渲染(ssr)之Next.js框架

于12-22 10:13 - rexhang_web -
Nextjs是 React生态中非常受欢迎的SSR(server side render——服务端渲染)框架,只需要几个步骤就可以搭建一个支持SSR的工程(_Nextjs_的快速搭建见 Next.js入门). 本文的案例代码来自于 前端标准模板项目. 提供了便捷强大的服务端渲染功能—— getInitialProps(),通过这个方法可以简单为服务端和前端同时处理异步请求数据:.

全方面解析微服务架构下的统一身份认证和授权 - 知乎

于12-20 11:44 - -
本文讨论基于微服务架构下的身份认证和用户授权的技术方案,在阅读之前,最好先熟悉并理解以下几个知识点:. 微服务架构相关概念:服务注册、服务发现、API 网关. 身份认证和用户授权:SSO、CAS、OAuth2、JWT. 文章在涉及到上述知识内容时,会附上参考链接. 当企业的应用系统逐渐增多后,每个系统单独管理各自的用户数据容易行成信息孤岛,分散的用户管理模式阻碍了企业应用向平台化演进.

用DDD指导微服务拆分 - ThoughtWorks洞见

于12-10 07:32 - -
对于服务拆分的逻辑来说,是先设计高内聚低耦合的领域模型,再实现相应的分布式系统. 服务的划分有一些基本的方法和原则,通过这些方法能让微服务划分更有操作性. 最终在微服务落地实施时也能按图索骥,无论是对遗留系统改造还是全新系统的架构都能游刃有余. 开发者在刚开始尝试实现自己的微服务架构时,往往会产生一系列问题 :.

服务注册中心 | 记一次 Consul 故障分析与优化

于11-22 03:52 - 爱奇艺技术 -
在微服务体系中,服务注册中心是最基础的组件,它的稳定性会直接影响整个服务体系的稳定性. 本文主要介绍了爱奇艺微服务平台基于 Consul 的服务注册中心建设方式,与内部容器平台、API 网关的集成情况,并重点记录了 Consul 遇到的一次故障,分析解决的过程,以及针对这次故障从架构上的优化调整措施.

从项目到产品化转型,从产品到运营和SaaS服务构建(201116)

于11-16 08:03 - 人月神话 - IT咨询
今天谈下在进行产品规划的时候,从产品化到运营化方面转型的一些思考. 对于大部分的软件企业来说,最希望实现的就是产品化,简单来说就是将自己开发的软件变成一种通用型的可以类似光盘快速零成本负责的产品,这种软件产品只需要少量的现场服务或支撑就能够方便客户快速的开始使用,类似微软的操作系统和Office办公软件.

[ 翻译 ] 微服务架构及设计模式

于11-12 10:39 - -
本文介绍了主流常见的微服务模式. 因此,了解如何处理微服务架构(MSA)以及一些微服务设计模式,一个微服务架构的一些通用目标或者设计原则是很有价值的. 下面是在微服务架构方案中值得考虑的四个目标[1]. 1、缩减成本:MSA将会降低设计、实现和维护IT服务的总体成本. 2、加快发布速度:MSA将会加快服务从想法到部署的落地速度.

数据显示:阿里超越IBM成为第四大公有云服务提供商

于11-09 16:52 - 小狐狸 - TechWeb
【TechWeb】11月9日消息,据国外媒体报道,最新数据显示,阿里巴巴超越IBM,成为第四大公有云服务提供商,仅次于亚马逊、微软、谷歌,但领先于甲骨文. 几周前,市场研究机构Synergy发布的最新数据显示,亚马逊在云基础设施市场上占据了33%的份额,排名第一,其次是微软(18%)、谷歌(9%)、阿里巴巴(5%)、IBM(5%)、Salesforce(3%)、腾讯(2%)、甲骨文(2%)、NTT(1%)、SAP(1%).

中国电信宣布未来将把云计算服务作为主业

于11-09 19:37 - - 行业云
雷锋网消息,近日,在广东举办的第十二届天翼智能生态博览会论坛上,中国电信宣布未来将把云计算服务打造成为中国电信的主业. 同时,中国电信将采取混合多云的云网融合策略,不仅是中国电信自身网络与天翼云的深度融合,还是多云和多网的融合. 对于一家电信运营商来说,这无疑是一次具有历史意义的战略转变. 事实上,中国电信在云计算方面早有布局,自2012年正式推出“天翼云”以来,在政企、广电等领域打造了众多业务上云的实例.

浅谈 Kubernetes 中的服务发现 | 伪架构师

于11-09 18:56 - -
Kubernetes 服务发现是一个经常让我产生困惑的主题之一. 深入了解 Kubernetes 服务发现. 要了解服务发现,首先要了解背后的网络知识. 这部分内容相对浅显,如果读者熟知这一部分,完全可以跳过,直接阅读服务发现部分. 开始之前还有一个需要提醒的事情就是,为了详细描述这一过程,本文略长.

微服务设计模式:防腐层(Anti-corruption layer)_琦彦-CSDN博客

于11-04 19:14 - -
 AzureCAT 模式和实践团队在.  Azure 架构中心发布了.  9 个新的微服务设计模式,并给出了这些模式解决的问题、方案、使用场景、实现考量等. 微软团队称这 9 个模式有助于更好的设计和实现微服务,同时看到业界对微服务的兴趣日渐增长,所以也特意将这些模式记录并发布. 下图是微软团队建议如何在微服务架构中使用这些模式:.

spring-cloud-kubernetes的服务发现和轮询实战(含熔断)_程序员欣宸的博客-CSDN博客

于11-01 08:38 - -
本文是《spring-cloud-kubernetes实战系列》的第四篇,主要内容是在kubernetes上部署两个应用:Web-Service和Account-Service,通过spring-cloud-kubernetes提供的注册发现能力,实现Web-Service调用Account-Service提供的http服务;.

谈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 支持的功能更加强大,更适合微服务架构:.