软件的首要技术使命：管理复杂度。              —— «代码大全(第二版)» 在互联网软件开发场景下，产品从0到1的技术挑战往往不是最难的，因为快速上线抢占市场往往是最高优先级， 技术实现上往往可以做减法。然而，从1到100过程中，系统可能变得越来越难以维护，事实上，单从完成需求开发来说， 最简单易懂的Controller -> Service -> DAL这样的三层架构也能实现，不断在这个基础上扩展，就会 造成系统臃肿，学习成本、开发成本以及维护成本越来越高，因此在这个过程中，团队会逐步沉淀出一套大家都能接受 的应用架构规范。一套好的应用架构值得参考学习，特别是架构的演进过程，可以发现很多共性问题。它山之石可以攻玉， 阿里开源的COLA架构是其中的优秀代表，重要的是，COLA架构不是一套架构思想的陈述，而是可以落地的架构实现。 应用架构的目标： 定义一套良好的结构； 治理应用复杂度，降低系统熵值； 从随心所欲的混乱状态，走向井井有条的有序状态。 COLA的初衷就是要在架构层面控制软件复杂度，这张图片看到过多次，形象生动地展示了COLA解决的问题： 整体分层结构 应用系统确定分层很重要，每一层各司其职，下层对上层屏蔽细节。...

对每个软件开发者来说，SOLID软件设计原则以及GoF总计的23种设计模式是耳熟能详的，其实完整地记下这些内容实际是很困难的， 更多的是在开发中能深入理解，在做技术设计时能灵活使用。 这些概念已经提出很久了，其实除了这些条款，在开发大型企业级应用时，开发者们也总结了一些其他的设计原则和设计模式，在此搜集总结一下。 — 1. SOLID设计原则 SOLID的定义： Single Responsibility Principle（SRP）：单一职责原则 Open Closed Principle（OCP）：开闭原则 Liskov Substitution Principle（LSP）：里氏替换原则 Interface Segregation Principle（ISP）：接口隔离原则 Dependence...

每个架构师都应该研究下康威定律 康威定律解读 如何优雅做好项目管理？

在一个苛刻的数据存储环境中，有很多可能出错的场景，如数据库网络连接错误、部分更新、数据覆盖以及各种 并发场景下读写产生的奇怪问题，事务技术是解决此类问题的首选方案，它可以将多个读写操作绑定在一起成为 一个逻辑单元，作为一个整体要么成功提交要么失败回滚，不会出现中间状态，简化应用层处理逻辑。 ACID 1983年提出用于描述数据库容错机制。需要注意各家数据库厂商宣称的”兼容ACID”其实实现方式并不相同，达到 的效果也是各不相同，甚至相同术语在不同厂商解释都有区别，因此这个词语更像是营销手段。 原子性 作者认为使用可终止性更准确，即出错时终止操作并丢弃修改。 一致性 概念很宽泛，不同场景解释不一样。这里解释为：对数据有特定预期状态，任何更改必须满足约束。 作者认为ACID这个缩写就是为了构造单词强行拼接，一致性不是数据库提供的基础能力，而来自应用层，不应该和AID并列。 可以这样理解，应用层通过AID，可以实现C。 P.S. 周志明在凤凰架构中同样提到，这个概念很有误导性，很多书籍博客强行解释其关联，与之对应的BASE更是离谱， 完全无法说明其基本含义。 隔离性 并行执行的多个事务互不影响，和串行依次执行效果一样。经典数据库教材将隔离定义为串行化，但由于性能问题使用很少， 数据库厂商甚至很多根本没有实现，一般退而求其次使用更低一些的隔离级别。 持久性 事务一旦提交，数据变更不会丢失，写入非易失性存储。...

Go语言作为C语言家族的年轻一员，最初Google的设计者站在前人的肩膀上，其目标就是能够给程序员带来快乐、匹配未来硬件发展趋势，且适合开发大型软件系统。 其核心思想就是： 追求简单，少即是多 偏好组合，正交解耦 原生并发，轻量高效 面向工程，自带电池 一些最佳实践: 1. 使用gofmt格式化代码 当代码开发人员还在争论不同代码风格时，Rob Pike告诉你：gofmt的代码风格不是某个人的最爱，而是所有人的最爱。通过这种”独裁”的方式，终结了关于 代码风格好坏的争论。因此团队开发中，提交代码前一定记得使用gofmt格式化代码。 2. 命名相关 包名使用小写字母 包名尽量与导入路径最后一个路径分段保持一直 变量名使用小驼峰命名法，如需导出使用大驼峰 变量声明与使用的距离尽量短 常量使用大写字母 3....

https://github.com/debuginn/golang-developer-roadmap-cn

最近在排查线上问题时碰到个诡异的问题，error日志中的异常栈没有了，只有一行： java.lang.NullPointerException 于是去查了网上文章，都指向一个JVM启动参数： OmitStackTraceInFastThrow 这个参数默认是开启的，解释是： The compiler in the server VM now provides correct stack backtraces for all “cold” built-in...

Mysql的主-备-从部署架构是经典方案，主库执行写操作，从库分担读压力。但是也会产生主从数据不一致的问题，从库拉取主库binlog同步数据， 必定存在延迟，从客户端来看，总是希望写入之后立即能读取最新数据。否则会造成比如用户支付成功后查看订单详情还是未支付状态。 1. 强制查询走主库 这种方案需要在业务层面区分出哪些查询必须读取实时数据，哪些查询可以接受延迟。对于不能接受延迟的查询，强制路由到主库，这种方案属于大力出奇迹， 能够保证读到最新数据，但是如果从业务层面权衡，比如交易场景下，可能会发现所有的查询都要求实时，这样读写分离就名存实亡了。 其实，在实际生产中，碰到过数据延迟的问题，解决方案就是修改路由强制走了主库，这种方案足够简单，而且数据库层面在设计时也有性能的冗余，问题就 这样简单的解决了。 2. 查询前sleep方案 这种方案看起来很傻，我们悲观的认为一定会出现延迟，因此在查询之前固定给一个延迟时间，这样等这段时间数据同步了再查询，但是这样没有考虑当前的 主从同步延迟情况，一刀切给一个延迟，在高并发系统，接口都加一个延迟，可能引起更大的性能问题。 3. 根据当前延迟情况决定查询路由 这种方案相比2的一刀切要合理些，首先看看当前从库的数据同步状态，然后根据同步完成与否确定是走从库还是主库。具体判断是否有同步延迟可以基于seconds_behind_master 、对比同步位点、对比gtid集合等方法。但是还存在一个问题，上面这些方式判断是否有延迟，是基于从库收到的binlog是否执行完了，那么就存在虽然当前 主库同步过来的日志都执行完了，但是还有主库已经提交事务但日志还没有拉过来的情况，因此也不是万无一失的。 4. 半同步复制+延迟判断 如果binlog是异步复制，那么主库提交事务完成请求就返回了，如果是半同步复制semi-sync，大致流程就是：...

收藏一组文章，关于支付系统的架构概览。 https://cloud.tencent.com/developer/inventory/13628

1. 网络编程的抽象 网络编程可以抽象为以下步骤： 读请求（read request） 读解析（read decode） 处理程序（process service） 应答编码 （encode reply） 发送应答（send reply） 最古老的模式就是单线程处理，服务端阻塞在套接字，来一个请求依次跑一遍流程，每个请求依次排队处理， 这种方式在互联网时代已经完全无法应付了。 改进一下，每当来一个请求，都开启一个线程去处理(或者更好一点，用一个线程池)，但是依然存在问题：当客户端多，并发数较大时，需要创建大量线程来处理连接，系统资源占用较大。 同时，连接建立后，如果当前线程暂时没有数据可读，则线程就阻塞在read操作上，造成线程资源浪费。 解决read阻塞问题的最简单的方式是将 read...

1. 线程实现的几种方式 线程是比进程更轻量级的调度执行单元，线程的引入可以把一个进程的资源分配和执行调度分开，线程可以共享进程资源，如内存、文件IO等，又可以独立调度使用CPU资源。 1.1 使用内核线程 内核线程：Kernel Level Thread（KLT），是由操作系统内核直接支持的线程，内核通过调度器讲线程任务映射到处理器上。 轻量级进程： Light Weight Process（LWP），内核线程的高级接口，用户进程通常不会直接使用内核线程，而是使用LWP提供的接口实现线程功能，每一个轻量级进程都对应一个内核线程，这是一种1:1的线程模型。 在现在常用的Oracle JDK和Linux操作系统环境下，使用的是这种模型。 1.2 使用用户线程实现 用户线程：User Thread（UT），通常来看，用户线程就是完全建立在用户空间的线程库上，对操作系统内核无感知，用户线程的建立、同步、销毁和调度完全在用户态中完成。线程切换不需要到内核态操作，因此操作可以是非常快速且低消耗的，也可以支持规模更大的线程数量。这种线程模型是1:N的。 由于用户线程的调度完全由用户程序控制，因此实现比较复杂，Java历史版本曾经使用过这种模型但最终放弃。 1.3...

Expert One-on-One J2EE Development without EJB是Java企业级应用开发的经典之作，可以从中看到Java企业级应用开发框架的发展历程、历史负债，从该领域顶级的架构师、Spring之父Rod Johnson的视角来看怎样解决这些问题，引出Spring的诞生以及其重要价值。 1. J2EE/EJB的问题 1.1 EJB之过 规范中很多已经过时，例如代码生成机制，在J2SE1.3提出动态代理后已经没有必要。 webservic的发展使得RMI没有那么必要。 实际开发中，EJB定义的一套体系结构是否具有普遍性值得怀疑。 为了解决这些问题，EJB规范日益复杂，以至于很多开发者无法理解。 开发效率低，通过IDE掩盖复杂性。 测试驱动开发变得流行，EJB很难测试。 …… 根源：以规范为驱动，成功的标准是从实践中发展出来的，而不是由哪个委员会创造出来的。 1.2...