徐大美1

摘要： package test; import org.testng.annotations.Optional; import org.testng.annotations.Parameters; import org.testng.annotations.Test; public class test0 阅读全文

摘要： # 洋芋饭的个人主页 <table border="1" cellspacing="0" align="center"> <caption font-size=“28px” margin-bottom=“10px” align="center">个人简历</caption> <tr align="c 阅读全文

摘要： 1，好的代码风格，好处多多，比如让自己逻辑更加清晰、提高reviewer的效率、减少新人的学习成本、避免不必要的bug等等。其中通过badcase 和 goodcase的对比强烈。 2，系统在升级过程中除了功能的满足，还要具有可监控性，通过log埋点等监控系统的可用性、性能等，非常推荐。因为功能上线 阅读全文

摘要： 修改软件的四个起因 添加新特性和修正bug 软件用户要依赖于软件的行为，用户喜欢添加行为，讨厌改变和移除行为。如果我们必须改变代码，那么我们就是在改变行为。如果我们只是往其中添加代码并调用它，则通常是在添加行为。 改善代码（重构） 在不改变软件行为的前提下改善其设计的举动称之为重构。其关键在于在重构 阅读全文

摘要： 一、修改软件的起因及其本质。 修改软件是任何一个开发人员所面对的问题，软件是否容易修改，被修改后的软件是否变得更好，是每一个开发人员都知道必须关注但是在实际开发过程中却往往忽视的问题。有多少人在接手一个新项目时抱怨新项目的遗留代码质量太低？又有多少人愿意或者说有能力去将一个让人崩溃的代码逐步改善？ 阅读全文

摘要： 、安全问题是木桶效应。 我们需要做的是对于安全的排查，需要全面覆盖，除非子站在部署上用户体系上彻底隔离。 2、开发层面：不要信任客户端的任何东西。 对于HTTP协议，不管是头里面的东西（来源、客户端类型、Cookie）还是正文里面的东西，任何数据都是可以伪造的。我们往往会觉得Get的东西暴露在浏览器 阅读全文

摘要： 由于业务发展到一定层度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯，面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障的时候会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。 微服务是真 阅读全文

摘要： 高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。 场景中的定时领取是一个高并发的业务，像秒杀活动用户会在到点的时间涌入，DB瞬间就接受到一记暴击，hold不住就会宕机，然后影响整个业务； 大型网站要很好支撑高并发，这是需要长期的规划设计 在初期就需要把系统进行 阅读全文

摘要： 解决问题能力不是天生的，自然得靠后天的经验积累。我们工作中会遇到各种各样的问题，比如需要去跟踪调试产品所产生的bug，又比如说使用第三方组件所遇到的一些问题，再比如说使用一些插件或者IDE所产生的一些编译问题。这个时候第一反应不是去别人那里寻求帮助，而是自己尝试去看去解决问题。 当遇到阻塞性问题的时 阅读全文

摘要： 三架马车是指微服务、消息队列和定时任务 服务有三个层次： 聚合业务服务：高层次的串起来整个流程的具有完整业务形态的业务服务。和基础业务服务不同的是，这里是在完整描述一方面的业务，这个业务往往是由各种基础业务拼装组合起来的。和不同外部合作方的不同合作形式，给用户提供的产品的不同服务形态，都决定了聚合业 阅读全文