摘要：
本文作者通过分析微服务的常见优点能解决的问题，提出如何使用单体应用来缓解这些问题，最终指出采用微服务还是单体架构要根据团队实际情况，而不是为了微服务而微服务。作者最后给出建议，中小团队和新型团队，建议采用单体架构，大中型团队，可以采用微服务架构，但要充分权衡。
在 Web 软件架构方面，微服务架构非常流行，它有大量高知名度的实践者和支持者，如Facebook、Uber、Groupon、Klarna、Amazon、Netflix、eBay、Comcast等。
但是，你很可能不属于这些公司。也就是说，你的团队很可能与这些公司的团队不一样，你没有面临与他们相同的问题。
当然，如果你恰好就属于这些公司（但极大可能你不是），请停止阅读。你们可能就是需要微服务的。 阅读全文
摘要：
一群高智商青年在餐厅吃饭，餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉，而标识为胡椒粉的瓶子里装得却是盐，他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个空碟子。当他们叫来服务员，准备炫耀他们的天才想法时，只见服务员什么也没说，只是拿起盐瓶和胡椒粉瓶，互换了瓶盖……
在我们软件工程中，同样一件事情可以有很多种解决方案，我们翻开那继承下来的祖传代码，系统堆叠了太多它不需要或者它不适合的动态扩展、规则引擎、条件分支等等。原本并不复杂的业务最终得到的还是一片混乱，是我们的做法还是太过简单吗，或许本质上是我们并不擅长处理『简单』。 阅读全文
摘要：
本文我们来探讨下如何引入分布式锁解决本地锁的问题。本篇所有代码和业务基于我的开源项目 PassJava。 阅读全文
摘要：
导读：设计模式能够帮助我们优化代码结构，让代码更优雅灵活。有哪些常见的设计模式？如何合理运用？本文分享作者对工厂模式、单例模式、装饰模式、策略模式、代理模式和观察者模式的理解，介绍每种模式的模式结构、优缺点、适用场景、注意实现及代码实现。 阅读全文
摘要：
导读：什么是时延？在电信系统中，不同应用对时延的要求是怎样的？如何通过部署架构降低网络传输时延？本文通过介绍云网络时延的构成，并对其进行量化分析，分享在不同云网络时延要求下，不同应用对应的部署架构，并简单分析了5G时代对应用部署架构的影响和度量云网络时延的工具。 阅读全文
摘要：
最近看了一本书《解构-领域驱动设计》，书中提出了领域驱动设计统一过程（DDDRUP），它指明了实践 DDD 的具体步骤，并很好地串联了各种概念、模式和思想。因此，我对书本内容做了梳理、简化，融入自己的理解，并结合之前阅读的书籍以及实践经验，最终形成这篇文章。希望可以帮助大伙理顺 DDD 的各种概念、模式和思想，降低上手 DDD 的门槛。 阅读全文
摘要：
随着计算机系统的规模越来越大，业务量的迅速提升和互联网的爆炸式增长，集中式系统采用大型主机单机部署带来了一系列问题：系统大而复杂、难于维护、发生单点故障引起雪崩、扩展性差等。这些都使业务面临巨大的压力和严重的风险，为了解决集中式系统架构面临的痛点，分布式系统架构逐步走上舞台。分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统，可以很好的解决系统扩容、可用性以及降低成本。 阅读全文
摘要：
Elasticsearch（简称：ES）功能强大，其背后有很多默认值，或者默认操作。这些操作优劣并存，优势在于我们可以迅速上手使用 ES，劣势在于，其实这些默认值的背后涉及到很多底层原理，怎么做更合适，只有数据使用者知道。用 ES 的话来说，你比 ES 更懂你的数据，但一些配置信息、限制信息，还是需要在了解了 ES 的功能之后进行人工限制。
你是否遇到：在使用了一段时间 ES 之后，期望使用 ES 的其他功能，例如聚合、排序，但因为字段类型受限，无奈只能进行reindex等一系列问题？
题主在遇到一些问题后，发现用 ES 很简单，但是会用 ES 很难。这让我下定决心一定好好了解 ES，也就出现了本文。 阅读全文
摘要：
纵观软件研发的发展历程，如果说“业务需求开发”是核心主线的话，那么研发效能建设就是这一核心主线之外最大的一条支线。每个历史阶段的研发效能所面对的主要矛盾次要矛盾都不一样，因此大家可以看到，在不同的历史阶段产生了不同的“研发效能提升产品”：从文本编辑器到带有各种功能的 IDE（Integrated Develop Environment），从单一的命令行脚本到覆盖代码发布全生命周期的 CI/CD 系统，从各种“上古时代”的协作表格或文档到目前已经发展出的横跨软件研发生命周期、覆盖软件开发关键维度的在线协作系统，似乎你能想到的降本提效的方法和途径，都有人帮你做了专业的产品用来满足你的各种要求和与众不同的偏好。 阅读全文
摘要：
软件交付的终态是提供一个稳定可预期的系统，可预期的系统要确保环境和软件制品的一致性。而在软件研发协作的过程中，无论是制品、环境，还是发布过程，往往都是定义在代码里的。
软件交付体现为发布，而提升交付能力的目标，是要发的容易，发的频繁，增量要多，每次发的时间要少。 阅读全文
摘要：
程序员拥有一个较好的编程原则能使他的编程能力有大幅的提升，可以使其开发出维护性高、缺陷更少的代码。以下内容梳理自StactOverflow的一个问题：编程时你最先考虑的准则是什么？ 阅读全文
摘要：
现今有越来越多的企业开始采纳云原生理念进行应用架构转型。而 K8s 和微服务是云原生的两大支柱，随着云原生浪潮而被广泛应用。
对多数应用而言，提供对外服务的使命并不会改变，相比于原来的单体应用，微服务架构下的应用的服务出口更多，管理更繁琐，微服务网关也应运而生；而 K8s 也提供了多种方式来暴露应用的服务，各种 Ingress 实现百花齐放。面对众多技术方案，我们如何做出合理的选择，规避潜在风险，本文将给出一些选型建议，供大家参考。 阅读全文
摘要：
一、系统性能问题五大特性
二、系统性能排查方略
三、MySQL开发规范和常见调优策略
四、MySQL性能管控体系
五、未来展望 阅读全文
摘要：
分享概要
一、业务场景
二、架构演进
三、架构设计
四、稳定性
五、效率 阅读全文
摘要：
select/poll/epoll 是 Linux 服务器提供的三种处理高并发网络请求的 IO 多路复用技术，是个老生常谈又不容易弄清楚其底层原理的知识点，本文打算深入学习下其实现机制。
Linux 服务器处理网络请求有三种机制，select、poll、epoll，本文打算深入学习下其实现原理。
吃水不忘挖井人，最近两周花了些时间学习了张彦飞大佬的文章 图解 | 深入揭秘 epoll 是如何实现 IO 多路复用的 和其他文章 ，及出版的书籍《深入理解 Linux 网络》，对阻塞 IO、多路复用、epoll 等的实现原理有了一定的了解；飞哥的文章描述底层源码逻辑比较清晰，就是有时候归纳总结事情本质的抽象程度不够，涉及内核源码细节的讲述较多，会让读者产生一定的学习成本，本文希望在这方面改进一下。 阅读全文
摘要：
序：
之前看过杨振宁的一个采访，说他最大的成就，不是获得了诺贝尔奖的研究，而是之前的一个普通理论的研究：他坚信事物是遵循一定规律的，不是大家认为的不可捉摸，花了7年时间，陆陆续续，终于找到了一个很好的解释，并且幸运的是，这个研究结果可以覆盖非常多的场景。
当我看到这个采访的时候，内心触动到的一个点是：尝试寻求表象背后的规律或者通用解释，是能够帮助更多的人、产生更大的影响的，这也应该是我们应该努力并坚持的方向。 阅读全文
摘要：
作为卓越工程文化的一部分，Code Review其实一直在进行中，只是各团队根据自身情况张驰有度，松紧可能也不一，这里简单梳理一下CR的方法和团队实践。 阅读全文
摘要：
写在前面：
写这篇文章的目的是为了能够更好的帮助刚入职的新人了解这个岗位和自己的工作，也想谈谈自己工作一年来对这个领域的了解程度，做一个小小总结吧～ 阅读全文
摘要：
在这30年的历史长河中，中国服务器一直走“边模仿边创新”的道路。但始终无法独立走上“自主可控”的道路，核心是芯片。
这不单是服务器的问题，是所有IT产业面临的终极问题。
本文聚焦在2010年前后至今的10多年。明显看出，我国服务器本土厂商在国际动荡的形势以及在国家政策引导下终于成为产业的主力军。这一切是如何发生的？ 阅读全文
摘要：
Let's Encrypt 是一个由非营利性组织 互联网安全研究小组（ISRG）提供的免费、自动化和开放的证书颁发机构（CA）。
简单的说，借助 Let's Encrypt 颁发的证书可以为我们的网站免费启用 HTTPS(SSL/TLS) 。
Let's Encrypt免费证书的签发/续签都是脚本自动化的，官方提供了几种证书的申请方式方法，点击此处 快速浏览。
官方推荐使用 Certbot 客户端来签发证书，这种方式可参考文档自行尝试，不做评价。
我这里直接使用第三方客户端 acme.sh 申请，据了解这种方式可能是目前 Let's Encrypt 免费证书客户端最简单、最智能的 shell 脚本，可以自动发布和续订 Let's Encrypt 中的免费证书。 阅读全文
摘要：
一、背景 作为在后端圈开车的多年老司机，是不是经常听到过，“mysql 单表最好不要超过 2000w”，“单表超过 2000w 就要考虑数据迁移了”，“你这个表数据都马上要到 2000w 了，难怪查询速度慢”。 这些名言民语就和“群里只讨论技术，不开车，开车速度不要超过 120 码，否则自动踢群”， 阅读全文
摘要：
本文从 5W1H 角度介绍了分库分表手段，其在解决如 IO 瓶颈、读写性能、物理存储瓶颈、内存瓶颈、单机故障影响面等问题的同时也带来如事务性、主键冲突、跨库 join、跨库聚合查询等问题。anyway，在综合业务场景考虑，正如缓存的使用一样，本着非必须勿使用原则。如数据库确实成为性能瓶颈时，在设计分库分表方案时也应充分考虑方案的扩展性，或者考虑采用成熟热门的分布式数据库解决方案，如 TiDB。 阅读全文
摘要：
“架构制图”这词乍一听似乎有些晦涩，但如果提起“工程制图”，相信绝大部分工科背景的程序员们都不会陌生，甚至还能共同感慨下那些年一起伏在宿舍左手圆规，右手直尺，徒手作图到深夜的日子。
软件工程也是工程，因此传统工程制图的一些基本理论，在软件行业同样适用。但另一方面，软件与实体制造业之间还是有着本质区别，所以在制图方面的需求和方式也大相径庭，无法直接套用。作为软件行业的从业者，你可以完全不懂工程制图，但你不得不懂架构制图 —— 这是任何程序员职业生涯的的必修课。 阅读全文
摘要：
为了应对大流量，现代应用/中间件通常采用分布式部署，此时不得不考虑 CAP 问题。ZooKeeper（后文简称 ZK）是面向 CP 设计的一个开源的分布式协调框架，将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用，分布式应用程序可以基于它实现诸如 数据发布/订阅、负载均衡、命名服务、集群管理、Master 选举、分布式锁、分布式队列 等功能。ZK 之所以能够提供上述一套分布式数据一致性解决方案，核心在于其设计精妙的数据结构、watcher 机制、Zab 一致性协议等，下面将依次剖析。 阅读全文
摘要：
1776 年亚当斯密发表《国富论》，标志着经济学的诞生。2004 年，一本名为《领域驱动设计·软件核心复杂性应对之道》的书问世，开辟了软件开发的一个新流派：领域驱动设计。看完这本书，十个人有九个人的感觉都是：似懂非懂，若有所得，掩卷长思，一无所得，我个人的感觉同样如此。出于兴趣，多年来仔细研读了几十本相关书籍，融汇贯通，逐步形成了自己的一套看法，本文就和各位分享一下。
冯友兰治哲学，提出“照着讲”和“接着讲”的方法论。近两年，我断断续续梳理出关于领域驱动设计的两个 PPT：《领域驱动设计》和《领域驱动设计四论》。前者的内容主要是关于 DDD 经典著作的读书笔记，可视为照着讲，以证明自己学有所本，讲的不是野狐禅；后者则是在继承的基础上所做的创新阐释，可视为接着讲，发前人之未发。本文重点围绕《四论》展开，从四个方面梳理出 DDD 的整个逻辑脉络。
曾见郭象注庄子，却是庄子注郭象。一些领域驱动设计的拥趸们，如果看到本文的论述和自己的理解相左，丝毫不用奇怪，本文阐述的四论，不是我注六经，而是六经注我。
本文不准备长篇大论，只是提纲挈领地梳理出 DDD 的核心脉络。 阅读全文