微服务落地反思以及有效落地

我今天的分享是微服务落地反思以及高效落地，我提前预告一下，这是针对团队的内容，如果你在网上看到微服务的视频和教程，你可以在云上自己去实现微服务的技术。 三个微服务案例带来的反思 1.1 Java遗留系统解耦 这个服务项目是我加入ThoughtWorks 第一年，2013 年 9 月 份，当时还不知道是微服务项目，2014 年微服务的概念才出现。 微服务落地的难点 我们看看微服务落地的难点。这些是我过去参与的微服务项目中常见的问题，说难点是因为这些问题需要更多的时间去思考和讨论，为微服务的架构决策提供依据。 《人件》中有一个萨提亚改变模型，当你有现有架构，引入微服务后会引起混乱，介入和辅导后，进行实践与整合，进行反馈和强化形成微服务架构。如果你做微服务做得很开心，说明到了微服务架构阶段了。 你做完微服务之后，你再去教初学者，效果不会很好。所以，在做微服务开始的时候，要做好微服务各种问题的记录，把一部分的成功经验交给新人，要比你找一个微服务很有经验的人去教新人要好得多。

微服务演进中的经验和反思

本文首发于 Gitchat，原文链接：微服务演进中的经验和反思 转载请标明出处。 大部分微服务的案例，我们往往都只能看到一个结果，很难看到其过程，特别是实践中的弯路。 经过前三篇的探讨，我们通过一个成功案例的三方面分析对微服务成功度量、技术演进和组织演进有了一个基本的认识。本文试着把我在客户身上看到微服务落地中那些经验和反思分享给大家。 如果不对微服务采取度量，你的微服务改造往往是失控的。 此外，并不是所有的应用都适合微服务架构。首先得明白微服务架构所解决的问题。 如果不进行估算和度量，你的微服务改造一定会因为失控而面对更多的麻烦。 所以，就像之前的文章提到的，做微服务的时候先不要急于你“是”一个微服务的架构。而应该在你的系统里先有一个微服务。 当我们开始实践微服务的时候，首先得先统一微服务的认识，让大家对微服务有统一的理解。其次是了解我们为什么要做微服务？微服务解决了你的什么问题，而不是陷入了盲目的技术崇拜中。

持续学习杂谈：总结与反思一、总结与反思二、微服务技术栈

一、总结与反思 去年在一篇文章中看到：工作后的学习，可以从两个方面着力——大的理论和底层的基础，对于中间的知识点可以放宽一点。 二、微服务技术栈 Java后端的开发人员，在技术方面不能仅仅满足于实现业务需求，而要对分布式系统（微服务）技术栈的各个组件捻熟于心，了解各个组件的使用场景、最佳实践、关键特性、跟同类竞品的比较、最好是阅读过一两个经典项目的源码 MQ） NSQ RocketMQ RabbitMQ Kafka NoSQL Redis & Codis Hbase ES 分库分表 TDDL cobar Mycat Sharding-JDBC 分布式服务跟踪

反思

重新打开去年4月份写的代码，改写一个写死的入参。虽然当时这个项目用 AngularJs 写的，还是1的版本。过了这么久，记忆也有点模糊了。

微信企业付款到个人钱包引发的坑之反思~！

企业付款到个人钱包也就是用户在微信公众平台提现可以直接打入提现者微信的钱包！ 但要满足： 1）企业开通微信支付90天 2）连续30天有交易才能开通此功能 今天有幸能开发此功能，我只能说我又涨知识了！！！在我编程的这条道路上我又多见到了一些坑！ /cert/rootca.pem"); 2）签名和提交数据的一致性问题： 微信签名文档上有详细的说明，但是我按照文档操作迟迟都是签名验证失败！ 最终总结如下注意点： （1）key是商户设置的密匙和微信支付统一下单的密匙是一样的 （2）加密的数据顺序和提交到微信接口参数值的顺序不能改变也就是我们在传递参数的时候直接讲数组转换成 ['desc']="xxxx"; $dataArr['mch_appid']="微信公众平台的appid"; $dataArr['mchid']="商户号"; $dataArr['nonce_str']

反思一次Exchange服务器运维故障

公司Exchange邮件系统邮件流故障的故障发现、故障处理和故障修复的过程记录和总结反思。帮助自己总结经验和吸取教训，同时也作为一次反面教材让其他运维或管理员吸取教训。 因为邮件服务是企业核心服务之一，加之已经有同事反馈遇到问题，因此此故障应该是重要紧急故障，必须尽快排除以恢复服务。 开始邮件服务器自身的排查： 因为是邮件服务器内部收发正常，因此直接登录邮件服务器，检查邮件服务器的其他可能影响因素 首先检查服务器负载，包括CPU、内存、磁盘空间、IO和网络等负载情况。 在 Exchange Server 2007 中，当集线器传输服务器或边缘传输服务器具有资源压力时，它会拒绝传入连接。 ---- 故障反思和总结 遇到故障或问题应该保持头脑冷静，切莫慌乱，不能自身乱了阵脚。很多运维或者管理员在遇到问题时首先想到是如何解决，而尝试各种办法解决无果后为了节约时间就想到回滚，这是不正确的。

学习过程反思

    本篇反思总结了一般的学习过程。掌握学习的方法，可以让你更高效地进行学习。这对于天天要学新技术的IT人员来说，是非常重要的。     本文反思了自己学习WPF过程中出现的一些问题，然后对以后学习的方法进行了重新设计。     学习工具的反思     其实之前已经听说过MS Expression的名字，知道专业的WPF界面都是用这个设计器做出来的。 反思     没有学精WPF的原因： 没有向高人请教。 没有由浅入深。 没有尝试使用界面设计工具。懒得去用。 和实践结合过少/没有系统的实践。 本文中对我个人出现的问题进行了一些反思，也画了新的学习方案。希望各位园友可以分享一下自己的框架学习经验，也希望能为我指正图中的不足之处，万分感谢。 :)

8月反思

所以，8月份凌帅虽然是有点抽离，但同时有更多的时间站在更远的视角来观察和反思自己的学习和投资。 加入007快一年时间了。这一年的时间是快速学习的一年，写了几十万字。

一个MySQL服务CPU 100%的优化案例反思

昨天在快下班的时候和同事处理了一起性能故障导致的服务器CPU 100%的案例。虽然问题解决了，但是在事后我做了一些反思，总体来说不够乐观。 快下班的时候，突然收到了一堆MySQL慢日志报警，同事反馈说晚上有一波活动，这个时候已经距离活动的开启时间很近了，然后就发现服务器的CPU瞬间到了100%，确切的说系统的负载在70倍左右。 1）快速定位瓶颈的层面，如果是业务服务出现问题，那么我们需要定位出一些边界，如果是数据库，则应该也有相应的辅助信息，最直观的，如果没有问题，用数字说话。

顾宇：成功的微服务的技术特征及其反思

这篇文章我们来介绍一下成功的微服务的技术特征以及我们在微服务落地中总结的经验。 成功微服务落地的技术特征 很多情况下，我们看到的微服务案例往往是一个结果，但缺乏过程。 我经历过的微服务案例没有百分之百的微服务架构，都是混合型的系统，也就是系统的一部分是微服务架构的。而微服务采用的比率取决于微服务的投入产出比。 我们做的微服务的架构有可能是微服务，有的可能不是微服务，它是分多种语言组成的。每一个应用就是一个代码库，这样管理起来非常的清楚。 我遇到的很多想采用微服务的团队往往纠结于自己“是不是”一个微服务架构。 我们就可以依据这个方式把成功的微服务不断地复制，就有了以上介绍的成功。 微服务落地反思 ? 总结了这么多，以上仅仅是我在我所经历的微服务改造项目里的观察。然而，一切并没有看上去那么美好。 当我们开始实践微服务的时候，首先得先统一微服务的认识，让大家对微服务有统一的理解。 其次是了解我们为什么要做微服务？微服务解决了你的什么问题，而不是陷入了盲目的技术崇拜中。

关于BEM的反思

反思BEM 在“学习爱BEM”中，我要表明我对BEM语法的新感受。 我很高兴地报告说，经过2年以上，我仍然对我的选择感到满意。 当我们在项目中选择代码风格时，我们使用BEM和ITCSS的组合。

Enum引发的血案，反思

对付费学习的反思

我反思，为什么学习了那么多知识，听了那么多牛人的话，生活的改变还是不大？ 何以解忧，唯有笑来。笑来老师的答案总是一针见血： 我们低估了学习任何一项技能所需要的重复练习次数。

国庆节前的反思

我在今年开始的时候给自己制定了全年读20本书的计划，6月就已经完成了，到我写这篇反思时，差不多已经读了30本开外的书，技术书10几本的样子。

“空降兵”的反思

包括现在建了前端的微信群，给大家无偿分享自己的技术技巧，管理方面积累的经验和教训，只是做的最简单的分享。只是传播正能量，如果大家觉得我能帮到大家，大家就帮下我，我会能帮到大家更多，仅此而已。

微信公众平台-微信服务号开发

文章目录 背景: 一、微信各个平台介绍 二、公众平台介绍 三、开发前准备 四、服务器配置 五、服务器验证 六、消息接收 七、客服消息 八、获取素材 九、相关工具 十、最终效果展示 总结 背景: 近期接到了涉及微信开放平台和微信公众平台相关的开发需求 ，开发过程中踩了许多坑，把相关问题整理记录下来以便巩固记忆，并把总结的经验分享出来，本篇分享微信服务号开发，希望可以给大家提供帮助 一、微信各个平台介绍 1、微信开放平台:面向开发人员，为网站、App提供微信第三方登录功能 IP为白名单，白名单以外的ip请求access_token接口会报40164错误，有了 access_token 才能调用微信的各种接口 四、服务器配置 开启服务器配置，开启以后服务号的推送信息将会传送到所配置的服务器中 ，微信服务器将发送GET请求到填写的服务器地址URL上，GET请求携带参数如下表所示： 参数 描述 signature 微信加密签名，signature结合了开发者填写的token参数和请求中的 微信服务器在五秒内收不到响应会断掉连接，并且重新发起请求，总共重试三次。假如服务器无法保证在五秒内处理并回复，可以直接回复空串，微信服务器不会对此作任何处理，并且不会发起重试。

微盟事情的反思：希望删库跑路永远是一句玩笑而已

读完需要9 分钟 速读仅需7分钟 相信这些天微盟的事情大家已经听说了。 ? 每每看到行业内的数据事故，我们在感慨之余，更需要的就是自省，因为这可以敲响我们已有状态的警钟。 微盟技术团队从一个创业团队一路走来，逐步建立了较为成熟的安全管理规范，对服务器和数据访问权限有着明确的分层和分级的授权管理制度，这次虽然有疏忽，实际上也是受害者。 根据事件跟踪得知，本次腾讯云从一开始就大力支持微盟，派了很多技术专家来帮助微盟和微盟的客户，使得恢复得以顺利开展。 但是问题要补救和修复，需要一套流程和制度和技术相辅相成，而且是一个持久改进的过程。 4.引入审计流程，实现独立的服务审计机制 审计环节是一个相对重要的独立环节，可以引入服务审计机制，可以通过独立的审计服务发现潜在的隐患，及时督正问题。 系统服务之间互相依赖，这是之前很少有人关注的，所以毫无疑问，这是一块硬骨头，我们需要重点关注。

【杂谈&反思】停止“埋头苦干”

诸如此类，还有相当多的案例，包括后来在做实验室的横向的时候，我也是经常按照自己的理解猛猛干了一堆感动自己的活，但其实根本没啥鸟用，还浪费了好多时间，仔细反思，我好像经常遇到这样的问题，于是我觉得好好总结一下为什么我会犯这样的毛病 以下为 Gemini 的回复：你的反思非常深刻且真诚。 四、针对 Gemini 给出方案的回复每条都挺好的，希望也能给遇到相同问题的朋友一些帮助，并且我认为这种进行一定程度的反思，然后向大模型寻求解决思路的方法也能够在一定程度上缓解我的焦虑，谢谢 Gemini

毕业两年的反思

其实真的不是这样的，技术是为需求服务的，再好的技术也是为了解决现实中的问题，只要能解决现实问题就算你用最low的算法，它也是一个好的产品。 还是前面说的技术是为需求服务的，学习也是一样的，为现实中具体的需求来学习。归根到底，学习应该是为了用新技术来解决现实问题。 但是我想如果作为一个程序员如果只是把自己限制在使用别人的库，只会复制粘贴别人的代码，这样永远是一个底层的码农，而做不了真正的程序员，还是那句话让它服务于具体的应用，比如你学习了HTTP协议之后，能不能仿照它 ，做一个能在嵌入式设备中使用的微型的HTTP服务器而不是直接上Apache，或者我能不能利用它的设计思想来提供类似的功能。

项目线上问题总结与反思

小编对项目中遇到的两次问题进行了总结反思，吸取教训，与君共勉。 ? 【一. 老用户升级后触发某个功能崩溃】 问题出现现象 【线上问题监控】新版本如果老用户升级后 触发获取转写语言崩溃。 反思】 后续改进 1、一轮测试过程中，对于有配置项的功能模块，除了模块功能重点关注外，新旧版本配置项兼容，需补全覆盖安装测试；覆盖安装测试，应该放在每个模块的测试中，而不仅是最后回归阶段。