阅读目录 一、前言 二、Tomcat 日志分割 三、定时清理日志 一、前言 随着每天业务的增长，Tomcat 的catalina.out日志 变得越来越大，占用磁盘空间不说。要查看某个时候的日志的时候，庞大的日志让你顿时无从下手，所以日志的切割的变得刻不容缓。而且，切割后的日志，还可以定期清理掉久远的日志…… 二、Tomcat 日志分割 我们采用日期形式切割catalina.out 日志，因此采用cronlog 软件切割： 1、安装 cronlog yum install -y cronolog httpd 2、修改bin/catalina.sh文件 (1) if ; then CATALINA_OUT=”$CATALINA_BASE”/logs/catalina.out fi 改为： if…
这篇文章主要介绍了Tomcat 日志切割（logrotate）详细介绍的相关资料,需要的朋友可以参考下 Tomcat 日志切割 logrotate是个强大的系统软件，它对日志文件有着一套完整的操作模式，譬如：转储、邮件和压缩等，并且默认logrotate加到cron（/etc/cron.daily/logrotate）作为每日任务执行。自动有了logrotate，我想不用再自己写日志切割脚本。 如下对Tomcat日志catalina.out日志切割 1 2 # ls -lh /usr/local/tomcat/logs/catalina.out -rw-r--r-- 1 www www 14M Aug 28 15:55 /usr/local/tomcat/logs/catalina.out 配置logrotate对catalina.out日志切割 1 2 3 4 5 6 7 8…
在项目迭代的过程中，不可避免需要进行项目上线。上线对应着部署或者重新部署，部署对应着修改，修改则意味着风险。 目前有很多用于部署的技术，有的简单，有的复杂，有的得停机，有的不需要停机即可完成部署。本文将对目前常用的部署方案做一个简单的总结。 蓝绿发布（Blue/Green Deployment） 1. 定义 蓝绿部署是不停老版本，部署新版本然后进行测试。确认OK后将流量切到新版本，然后老版本同时也升级到新版本。 2. 特点 蓝绿部署无需停机，并且风险较小。 3. 部署过程 部署版本 1 的应用（初始的状态） 所有外部请求的流量都打到这个版本上。 部署版本 2 的应用 版本 2 的代码与版本 1 不同(新功能、Bug修复等)。 将流量从版本 1 切换到版本 2。 如版本 2…
讲师介绍 任发科，网名常新居士，曾任职唯品会、会唐网、亚马逊、ThoughtWorks，有十余年软件开发、架构和管理经验。曾参与多个电商相关系统的研发工作，近年主要关注DevOps工具链的设计与实现，以及高效研发团队的组建与管理。 今天我主要是从两个方面去探讨DevOps，由于大部分的同学可能更多的是看到了运维这个层面，所以我更多侧重的是Dev这个层面，也就是从Dev到运维，因为正好是整个全流程走到这里，我们看到了一些实践，也看到了将来的一些机会和趋势，所以今天会谈一谈我们公司近两年做的过程，也就是我们怎么做DevOps。 一、从业务、系统发展看问题 从业务和系统的发展，我们来看当时面临的问题和解决的措施，有一些总结性和思考性的东西。就像程永新老师在企业级运维三板斧所说的，未来不是DevOps，关注方向的可能是AIOps这个层面，也就是说DevOps更要关注的是ADPaas平台，而在运维侧则更多的是AIOps，就像谷歌的系统是自治的，不需要人为介入，所以运维侧是要受到很大挑战的。 这是我当时加入公司时的一个基础组织架构，跟所有互联网公司，或者一些创业已经过了风险期的公司大致相似，这是标准化的建制，就是说业务和研发、测试、运维都有，是这样的一个结构。 敏捷与持续集成 第一个过程，当我加入到这个团队里面时，整个研发体系加上在一起大概40人左右。刚进去时我们做敏捷和持续集成，跟所有的创业团队一样，内部没有规范，做事图快，质量较低。大家在创业公司或者是一些中型公司呆过的话就会知道，基本上没有走到标准化流程阶段，基本上都会存在相同的问题，就是业务和研发对接的管理非常混乱，没有相对规范的流程。 开发做出来的东西提交测试时没有太多的责任心（在心理定位上将测试人员当作编码质量的防护网），里面Bug非常多。然后上线测试，我们当时让测试做构建，把这个包构建出来，最后交给运维，由运维负责上线。整个过程很乱，比如拷到某一个发版机器上，拷上去以后用文件夹打个标签交给运维，运维再往线上扔，扔到线上以后就要人肉一段时间，看一看没什么问题才回家睡觉。 存在问题：你可以看到基本上的问题就是，需求侧这面项目管理非常乱，研发的交付质量很低，会有很多返工的事。项目上线的周期长，问题非常多。 我们首先做的是基于持续集成的改善。从过程管理这个层面，我们把Scrum引入进来，对Scrum做了一定的调整。实际上最近在敏捷圈子里吵得非常厉害，各种方法论大家都不服，都认为自己代表了“天意”。但从企业的角度，尤其是我们解决问题的角度，用哪个都无所谓，能解决问题才是根本。所以我们根据企业当前人员情况对Scrum进行了裁剪，不是什么都要，明确哪些问题需要用Scrum去做。把Scrum流程引入之后，再用JIRA做需求管理、排期这些事情，然后内部用GitLab去做整个代码的管理，搭一个服务器，把UT做起来，很快能够得到好的反馈。这个是非常成熟的套路，如果用强制的方法做的话见效很快，基本上1-2个月就能梳理出来。 在我们做完了后会发现，这个过程不是那么顺，不是上来以后奇迹一般的就做好了，中间肯定有很多很多需要去沟通、协调的一些过程。你可以看到业务跟研发的对接相对来说变得好了，不一定非常流畅，但可控了。但研发到测试这边，你会发现它的墙变灰了，不是那么实了，因为当你有UT搭建起来后，其实提交的质量、责任已经放在研发这一侧了，这时候测试拿到的东西相对就好很多，它就不会来来回回地在底层的一些简单问题上掰扯。但这时运维这一侧还没有受到太大的影响。 存在问题：这时我们发现还是有一些问题，就是研发到测试的交付物不同源，一致性存在问题（我们后面会讲一致性的问题）；测试手工验证周期还很长，因为它没有做测试的自动化，即功能测试和性能测试都没有做自动化；项目上线时间长，因为没有触动到运维侧。所以这时候我们要做的就是持续交付的第一个版本，我们把它叫做持续交付的1.0。 持续交付1.0 持续交付的1.0做了什么事？就是我们现在大部分在40人以下的小团队要做的——一个交付流水线，其实多数团队都是这样做，就是加一个pipeline的插件，部署的脚本写在Jenkins里头，然后把它跟源代码放在一起，这就是我们现大部分持续交付的事情——加一个pipeline插件。我没有截那个图，这里画了一个大概的形式。 你可以看到之前的CI我们还需要做，但Jenkins有了一定的构建能力，并且通过pipeline插件我们可以做多环境的部署，只要构建出来以后一步一步往上推（Promotion），但在UAT到生产这一步需要人工做最后的审批，并不全自动化。 这里涉及到两个概念的差别呢？就是什么是持续交付，什么是持续部署，现在行业里头谈持续交付多一些，谈持续部署少一些。持续集成是关注在研发侧，不涉及到后面的自动化验证和部署的过程，但持续交付关注到了构建后的部署和验证，但它有一部分的手工验证过程，它可能在全线是贯通的，但最后的一步和中间验证都是手工的。而持续部署强调的是全自动，中间没有任何人为的干预，只要你一提交代码马上就开始通过部署流水线向生产流动。我们现在说的是持续交付，所以这在生产过程实际上还需要手工去审核的。但这个过程实际是有问题的，在系统很小的时候可以这么做，但团队变大的时候就有问题。 存在问题：什么问题？持续交付说只构建一次，然后在这个构建的产物上进行验证和部署，这就需要引入制品库。但是我们遇到了一些团队，你会发现实际上在代码的生成和验证的过程中，它都是从版本库里头直接拉代码回来，不断地拉代码，拉了以后再动态地打包，这样的话会有一些问题。 所以我们希望把制品库引进来，就是拿的东西是第一次就构建成功的东西，然后在这个上面不断地附加原数据。什么是原数据？就是经过或没经过单测，单测的百分比是多少，然后谁去验证它，这都是跟这个制品有关的一些行为和流程数据，它必须要记录下来，因为后期的活动可以基于这些数据去做选择。 制品库：Nexus->Artifactor->自研 我们整个制品库过程选择经过了3个阶段，最早的整个项目是用Java来做的，很自然的，我们就用Nexus做私库，去做制品的构建产物管理。因为它很容易解决依赖的问题，而依赖是很麻烦的事情。因为Nexus支持产品版本，不支持构建版本的追踪，同时它没有原数据管理的能力。 所以第二步我们跟JFrog对接，希望用它的Artifactory，这是用得比较成熟且用得比较多的，目前谷歌、腾讯、阿里也在用。但问题是公司体量不大，而专业版的Artifactory比较贵，我们负担这样的花费有点不划算，跟大家一样我们想用开源版本的，但社区版的Artifactory不支持多语言，而且它构建版本的支持要专业版，所以没办法，我们调研以后自己做，拿什么做？ 很简单，你可以搭一个类似S3的文件服务，把它放在文件服务上去。第二种方式我们用数据库去做，有些数据库实际上是可以去存二进制的大文件的，而且它可以很方便地做Key-Value的元数据管理，但自己研发制品库的问题在于并发、高可用和快速下发。在规模较小时，这些还不是问题。 它的好处是什么？加了制品库以后，我们能保证把构建版本和元数据打上去，在这样的话我们保证部署的都是同源的，而且一步一步可以在它的部署逻辑里头根据元数据经过选择，就是它没有经过前面的阶段或者到达一定的百分比我是不允许后面的阶段看到这个构建产物。 现在你可以看到我们的整个结构，就是说开发到测试的阶段实际上这个墙就没有了。这里说一下我们自己的业务，我们的业务基本上是支持公司内部的电商和公司内部的其它互联网产品。这时你可以看到测试到运维这边的墙实际上可以把它拿走，但运维这时还有一些问题就是他的事比较杂，为什么杂？因为应用的运维。我们可以把运维看成两部分，一部分是传统的运维或者说是基础设施和工具化的运维，另一方面是跟应用相关的运维，应用的运维我们也是放在运维团队的，这个安排实际上是不合适的。所以说运维的事就比较杂，不能专心地干自己特别擅长的事。 存在问题：这时我们发现运维人员需要维护大量的环境，包括应用的部署；第二，构建环境与生产环境的一致性是有问题的。为什么？比如说构建环境放在Jenkins里，如果去用它做构建的话，它的环境是定好的，例如JDK1.8，那我所有的东西只能在JDK1.8上去构建，但如果我要装JDK1.7呢？那就另搭一套环境去做它，比较麻烦。部署逻辑和Jenkins是紧耦合的，因为这些东西我们是在Jenkins里用脚本编程，而且它没有快速回滚机制。有些时候实际上是要快速回滚的，不能重新拉代码版本再部署一次。最后，依然需要大量的人员去做半自动化的测试。 持续交付2.0 用配置管理工具（Ansible）管理环境 这时我们就想做2.0的持续交付，最早我们是用Ansible做环境的管理，在持续交付2.0之前和持续交付1.0之间发生了一件事情：我们把大量的机器从阿里云上搬到自己的私有云上，在一年不到的时间我们搭建了OpenStack的私有云，一年里给公司节省的成本大概是在几百万左右，除了少量对外的一些服务必须要放在阿里云上，我们大部分核心计算都是放在内部的私有云上，这是我们运维团队做的非常大的贡献。我们到了2.0的阶段，实际上大部分的机器都是虚机。这时候加上Ansible以后，可以拿Jenkins去管这些集群的环境，这样的大家相对都用得比较多，就不过多解释。 存在问题：这时整个场景里可以看到，有一部分是应用的业务部署，有一部分是环境的部署、管理，但当真正去实践时发现有些问题。第一个是需要构建环境和生产环境的版本是一致的，即应用包依赖的版本一致，包括操作系统也是一致的。第二个就是需要构建工具的一致性，就是说，构建时比如说是1.9构建的，回滚时也必须要回滚到1.9进行重建，必须要把这个信息记录下来。…
CMDB，几乎是每个运维人都绕不过去的字眼，但又是很多运维人的痛，因为CMDB很少有成功的，因此我也把它称之为运维人的耻辱。 那么到底错在哪儿了？该如何去重构它？ 今天我想从我的角度来和大家探讨一下业务失败的原因，基于失败再去看重构的逻辑，也许会成功。 从失败中寻找成功的逻辑，往往是最有效的，那我们就来逐一看看： 1、组织的设计问题 我必须把核心原因归结成这一条，很多公司把CMDB的建设责任放到基础设施建设部门，由他们主导承建。最后他们梳理出来的核心逻辑是面向基础设施资源的管理，你在他们的CMDB中都能看到如下菜单，AIX主机是哪些，中间件有哪些，大小机有哪些，Oracle有哪些等等，这些都是和公司的IT运维部门组织结构是一一对应的。组织的隔离是CMDB失败的核心原因！ 这个里面能看到一些CMDB管理能力错位，拿两个例子来说一下： A、中间件。 一直搞不明白为什么中间件要作为一个单独的对象来管理，“皮之不存，毛将附焉”。没有主机，没有业务这个皮，哪来的中间件。把他单独拿出来管理，纯粹就是为了满足组织的一个管理视角。从来没人想过，这是主机上的一个资源对象，应该是一个附属资源，其实对他的信息管理和机器上的CPU、网卡一样。 B、进程对象，比如说数据库 这个是另外一种管理错位，是专业的管理平台应该去履行的管理职责，结果放到CMDB平台中了，然后CMDB管理了大量的动态属性，比如主备关系，服务状态等等，太复杂了。最简单的看，从主机的角度来说，他就是服务器上运行的一个进程而已。管它死活干嘛，那是监控系统做的事情，管它状态干嘛，那是**组件管理平台干的事情。 2、Excel是最好的管理工具 当组织隔离，不能够形成有效的信息互动之后，Excel更是之上的一次痛击。可能从外围思考，为什么不去解决现实层面上的问题，而选择了Excel？Excel很简单，特别是IT服务对象不多的情况下，几百个还是能够应对的。我就拿个Excel记录一下，然后svn上小组内共享一下就好了，反正我的信息也就我使用，别的小组也不用（组织的隔离性）。对它的思考，还是要回归的第一点，使用Excel是结果，但我比较反对Excel做法。每次建设cmdb的第一个目标，就说要消灭掉Excel。 3、去简就繁 这个是从产品本身说的，我看了几个开源的产品，oneCMDB和iTOP（建议大家都体验一下），界面都是复杂的要命，还有商业的产品（具体哪家不说了）。 首先必须要解决产品易用性的问题，易用性不够，你怎么让能用户有使用的欲望呢，以下是来自于UC做的CMDB系统产品截图： 其次还有一种信息复杂带来的易用性下降的问题。我看很多产品都管理了一些无光的信息，信息的管理归类也是有考究的，没归类好，用户又被淹没了。 拿主机来说，维护其核心需要的信息就好了，比如说固资编号、所在机房的位置信息、厂家信息、上架信息、进程端口信息、维护信息等等。这些信息都是有运维场景的，比如说位置信息+固资信息在驻场需要操作的时候有用；上架信息对于过保维修有用；进程端口对于监控有用；维护信息在运维申请资源的时候有空，谁也不想用经常故障的机器吧；主机状态位是用来做资源池管理+监控使用的。 很多配置的变更都是因为场景变更引起的，比如说机器搬迁导致机器的物理位置信息发生变化，那就搞一个机器搬迁流程吧；机器上的业务下线了，但进程信息没有清理，那是业务下线流程的问题…. 5、和应用没有关联，更别提场景关联了，就更别提主动场景了 很有意思的现象：客户的监控系统中监控的应用主机信息都是该系统中自行维护的，从来没有考虑从CMDB获取。也就是因为CMDB是另外一家产品，为啥呢？如果资源和应用关联起来了，并且由他来驱动监控，这个维护的动力是不是不一样呢？ 哪怕是你的CMDB系统能够支撑一下我上图中的工具盒子的能力，CMDB维护的动力不至于那么糟糕，它的数据也不至于那么糟糕。之前和人探讨过是先有操作系统安装把信息写到CMDB还是先有CMDB的信息然后再有操作系统安装的动作？当然是后者了。事实上在服务器采购分配上机架的时候，其实所有的信息都分配完毕，此时入库，就可以启动远程自动安装了。 其实还有很多原因，比如说物理世界和逻辑世界是独立的，物理世界发生的过程没法直接映射到CMDB系统中（有些配置信息需要进入固件中）；CMDB的对象Owner没有或者过多（Owner很累）；过分强调CMDB的基线作用，引入对比（动态变化的环境基线的作用应该下降）；夸大CMDB自动发现的作用等等。 说了很多的失败的原因，接下来就需要讨论一下解决方案了，既然讲重构，老王的重构逻辑是什么样的？ 第一、重构你的CMDB思维 建议大家不要把CMDB称之为CMDB了，那叫什么，就叫资源管理吧。为什么你要从改名字开始？老是叫CMDB，大家都回到过去的思维上了，道不清说不明的，或者各执己见。 一切皆资源！！！一切皆资源！！！一切皆资源！！！ 从基础设施的对象来说，计算资源、存储资源、网络资源、IP资源、机房资源等等，在CMDB的管理上，把你的资源对象罗列出来，关系梳理清楚，就可以构建其能力管理了。 从上层的业务资源来说，建立以应用为中心的资源管理逻辑，把 一切都看成应用的资源来看待。比如说Host，应用包、权限、RDS服务、cache资源等等。…
1. 背景 某TIC网站提供O2O服务，客户在线下单并点击在线支付，会跳转到支付宝收银台进行付款，付款成功完成后，支付宝会调用TIC网站接口，通知TIC网站付款成功。 2. 问题现象 测试中，发现支付成功完成后，TIC网站并没有收到支付宝的回调通知。经过排查后发现，该TIC网站的ssl证书链并不完整。 在线验证工具：https://cryptoreport.websecurity.symantec.com/checker/ 另一个工具：https://www.ssllabs.com/ssltest/ 工具三：https://ssltools.digicert.com/checker/ 3. 解决思路分析 由以上监测工具可知，ssl证书具体的问题为：Missing Intermediate Certificates GoDaddy 对 Intermediate Certificates的解释：https://sg.godaddy.com/zh/help/what-is-an-intermediate-certificate-868 4. 证书链原理 浏览器的安装包里，保存着一些它信任的根证书（公钥）。 证书发行商们为了安全，通常会将这些根证书对应的私钥保存在绝对断网的金库里。在金库里用这些根私钥，签发一些“中级”证书，这些中级证书的私钥拥有签发再下一级证书的权限。这些中级私钥被安装到在线服务器上，通过签发网站证书来赚钱。一旦这些服务器被黑，发行商就可以利用金库里物理隔离的根证书私钥，可以签发吊销令，消灭这些中级证书的信任，而不必让各家浏览器彻底不信任这家发行商的根证书。再签一条新的中级发行证书，又是一条能赚钱的好汉。 问题来了。 浏览器只认根证书。中级证书的认证，你（网站）得自己开证明。 一个正确配置的HTTPS网站应该在证书中包含完整的证书链。 比如以 openssl s_client -connect www.wosign.com:443…
今天开启了nginx的error_log，发现了三个配置问题： 问题一： 2011/07/18 17:04:37 2422#0: *171505004 an upstream response is buffered to a temporary file /opt/app/nginx/fastcgi_temp/9/80/0001539809 while reading upstream, client: 1.202.221.2, server: www.yongfu.com, request: “GET /recipe/all?cate=643&PHPSESSID=8c1135b85f1b5f90f55caab5ea7e1526 HTTP/1.0”, upstream: “fastcgi://127.0.0.1:9000”, host:…
介绍 SkyWalking 创建与2015年，提供分布式追踪功能。从5.x开始，项目进化为一个完成功能的Application Performance Management系统。 他被用于追踪、监控和诊断分布式系统，特别是使用微服务架构，云原生或容积技术。提供以下主要功能： 分布式追踪和上下文传输 应用、实例、服务性能指标分析 根源分析 应用拓扑分析 应用和服务依赖分析 慢服务检测 性能优化 主要特性 多语言探针或类库 Java自动探针，追踪和监控程序时，不需要修改源码。 社区提供的其他多语言探针 .NET Core Node.js 多种后端存储： ElasticSearch， H2 支持OpenTracing Java自动探针支持和OpenTracing API协同工作 轻量级、完善功能的后端聚合和分析 现代化Web UI 日志集成…
摘要： 数字化生态，以创新客户体验为核心，所有我们身边能感知到的变化都来自于渐近的创新。这些创新需要试错，需要不断的升级，并且创新往往与我们熟知的功能分离开来分别呈现。微服务对于传统单体架构的优势之一就在于，服务的拆分带来了更新、部署、管理的隔离性，让一些单独的服务可以进行创新和实验。 数字化生态，以创新客户体验为核心，所有我们身边能感知到的变化都来自于渐近的创新。这些创新需要试错，需要不断的升级，并且创新往往与我们熟知的功能分离开来分别呈现。微服务对于传统单体架构的优势之一就在于，服务的拆分带来了更新、部署、管理的隔离性，让一些单独的服务可以进行创新和实验。从而支撑了用户体验的不断升级，为实现企业数字化转型的过程，提供了技术架构层面的支撑。 我们现在已经可以很方便的通过一些电子商城购买运营的合约机，而无需到营业厅亲自办理相关的业务，这就是API Gateway的一种底层支撑。由于运营商通过API Gateway向第三方的商务平台开放了与套餐、机型销售等服务，并通过流控、鉴权等机制保障相关的安全性，才使得这样方便流畅的购物体验得以实现。 对于MOBA手游类玩家来说，“王者荣耀”是一款颇受欢迎的游戏。在一些场景下，我们会感知到“不停机更新”“体验服更新”这两种不同方式的更新形态，在底层，就是API Gateway或者类似技术的实现，支撑灰度发布，让一些新特性发布给体验服（比如传说中露娜的二技能变化，仅在体验服更新，实际上并未如传说中一样在S11赛季更新到正式服），或者特定的游戏用户，待功能完善或者稳定运行，再向正式服或者全部用户发布，让游戏玩家的体验可以更加流畅，甚至是无感知的升级。 这些只是微服务架构或者API Gateway所支撑的万千业务场景中的沧海一粟。 但微服务本身也会带来诸多问题，粒度小难以管理就是其中之一，本文即从这个角度，阐述了API Gateway所起到的作用和一些关键的技术要素。 以微服务为核心的分布式框架贯穿了普元数字化企业技术平台的APaaS层面，本文所介绍的API Gateway是其中的关键组成部分（图中标黄的部分）。 引言： 随着微服务的大红大紫，大家纷纷使用微服务架构来实现新系统或进行老系统的改造。当然，微服务带给我们太多的好处，同时也带给我们许多的问题需要解决。采用微服务后，所有的服务都变成了一个个细小的API，那么这些服务API该怎么正确的管理？API认证授权如何实现？如何实现服务的负载均衡，熔断，灰度发布，限流流控？如何合理的治理这些API服务尤其重要。在微服务架构中，API Gateway作为整体架构的重要组件，它抽象了微服务中都需要的公共功能，同时提供了客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日志统计等丰富的功能，帮助我们解决很多API管理难题。 目录： 一、什么是API Gateway 二、为什么需要API Gateway 三、API Gateway中一些重要的功能 四、API Gateway vs 反向代理 五、API Gateway对API的认证及鉴权…
前言 又是很久没写博客了，最近一段时间换了新工作，比较忙，所以没有抽出来太多的时间写给关注我的粉丝写一些干货了，就有人问我怎么最近没有更新博客了，在这里给大家抱歉。 那么，在本篇文章中，我们就一起来探讨一下 API 网关在整个微服务分布式架构中的一个作用。 背景 我们知道在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的系统他们可以自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。 但是在UI上进行展示的时候，我们通常需要在一个界面上展示很多数据，这些数据可能来自于不同的微服务中，举个例子。 在一个电商系统中，查看一个商品详情页，这个商品详情页包含商品的标题，价格，库存，评论等，这些数据对于后端来说可能是位于不同的微服务系统之中，可能我后台的系统是这样来拆分我的服务的： 产品服务 – 负责提供商品的标题，描述，规格等。 价格服务 – 负责对产品进行定价，价格策略计算，促销价等。 库存服务 – 负责产品库存。 评价服务 – 负责用户对商品的评论，回复等。 现在，商品详情页需要从这些微服务中拉取相应的信息，问题来了？ 问题…
Vinny Wang