随笔分类 - 软件工程
摘要：为了应对大流量，现代应用/中间件通常采用分布式部署，此时不得不考虑 CAP 问题。ZooKeeper（后文简称 ZK）是面向 CP 设计的一个开源的分布式协调框架，将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用，分布式应用程序可以基于它实现诸如 数据发布/订阅、负载均衡、命名服务、集群管理、Master 选举、分布式锁、分布式队列 等功能。ZK 之所以能够提供上述一套分布式数据一致性解决方案，核心在于其设计精妙的数据结构、watcher 机制、Zab 一致性协议等，下面将依次剖析。
阅读全文
摘要：1776 年亚当斯密发表《国富论》，标志着经济学的诞生。2004 年，一本名为《领域驱动设计·软件核心复杂性应对之道》的书问世，开辟了软件开发的一个新流派：领域驱动设计。看完这本书，十个人有九个人的感觉都是：似懂非懂，若有所得，掩卷长思，一无所得，我个人的感觉同样如此。出于兴趣，多年来仔细研读了几十本相关书籍，融汇贯通，逐步形成了自己的一套看法，本文就和各位分享一下。
冯友兰治哲学，提出“照着讲”和“接着讲”的方法论。近两年，我断断续续梳理出关于领域驱动设计的两个 PPT：《领域驱动设计》和《领域驱动设计四论》。前者的内容主要是关于 DDD 经典著作的读书笔记，可视为照着讲，以证明自己学有所本，讲的不是野狐禅；后者则是在继承的基础上所做的创新阐释，可视为接着讲，发前人之未发。本文重点围绕《四论》展开，从四个方面梳理出 DDD 的整个逻辑脉络。
曾见郭象注庄子，却是庄子注郭象。一些领域驱动设计的拥趸们，如果看到本文的论述和自己的理解相左，丝毫不用奇怪，本文阐述的四论，不是我注六经，而是六经注我。
本文不准备长篇大论，只是提纲挈领地梳理出 DDD 的核心脉络。
阅读全文
摘要：谈起消息队列，内心还是会有些波澜。
消息队列、缓存、分库分表是高并发解决方案三剑客，而消息队列是我最喜欢，也是思考最多的技术。我想按照下面的四个阶段分享我与消息队列的故事，同时也是对我技术成长经历的回顾。
阅读全文
摘要：资金核对的数据组装-执行-应急链路，有着千万级TPS并发量，同时由于资金业务特性，对系统可用性和准确性要求非常高；日常开发过程中会遇到各种各样的高可用问题，也在不断地尝试做一些系统设计以及性能优化，在此期间总结了部分性能优化的经验和方法，跟大家一起分享和交流。
阅读全文
摘要：建模对于大家来讲并不陌生，而且建模的方法也有很多，如用例建模、四色建模、事件风暴等，但在日常工作中，大家又觉得建模挺虚的：怎么把建模落到实际开发工作中。个人认为建模是分两部分：第一部分是业务概念建模，对现实业务抽取核心概念构建出模型（知识层）；第二部分是系统建模，系统建模是源于业务概念模型，遵循某些原则最终形成开发可落地的模型（操作层）。在本文中，给出建模的底层逻辑：用图形逻辑地表达现实业务的抽象，通过一些大家通识的技术案例讲述建模的过程。
阅读全文
摘要：DDD（领域驱动设计）是 Eric Evans 于 2003 年提出的解决复杂的中大型软件的方法，开始一直不愠不火。直到 Martin Fowler 于 2014 年发表的论文《Microservices》引起大家对微服务的关注，DDD 才重新慢慢的回到了大众的视野中。
DDD 这几年升温的同时，也收到了很多行业人员对 DDD 的负面意见，主要原因大概有“晦涩难懂过于抽象”、“很难找到实际的案例参考”、“不知道怎么落地”等。
笔者在学习 DDD 的过程中，也遇到了这些问题。不过在经过几个月的学习-实践，逐渐掌握了 DDD 的一些思想后，感觉还是确实有所受益，所以这里尝试用白话去总结我们从入门到实践的过程，尽量每一个概念都用我们的具体实现做出例子，希望能对想一起学习 DDD 的同事有所帮助。
阅读全文
摘要：本文主要讲解在 Git 仓库中如何管理大的二进制文件，详细介绍了什么是 Git LFS，Git LFS 是如何工作的，以及如何使用 Git LFS。
阅读全文
摘要：作为公司代码委员会 golang 分会的理事，我 review 了很多代码，看了很多别人的 review 评论。发现不少同学 code review 与写出好代码的水平有待提高。在这里，想分享一下我的一些理念和思路。
阅读全文
摘要：23种经典设计模式共分为3种类型，分别是创建型、结构型和行为型。
今天，我们把这3种类型分成3个对应的小模块，逐一带你回顾一下每一种设计模式的原理、实现、设计意图和应用场景。
还是那句话，如果你看了之后，感觉都有印象，那就说明学得还不错；如果还能在脑子里形成自己的知识架构，闭上眼睛都能回忆上来，那说明你学得很好；
如果能有自己的理解，并且在项目开发中，开始思考代码质量问题，开始用已经学过的设计模式来解决代码问题，那说明你已经掌握这些内容的精髓。
阅读全文
摘要：高并发解决的核心问题是在同一时间上有大量的请求过来，然后我们的系统要怎么抗住这些请求带来的压力。本文从基础设施层、服务端架构层、服务应用层分别做了一个简单的梳理，在每一层通过什么的方式去抗并发，给大家提供一个思路。
阅读全文
摘要：2015 年 HTTP/2 标准发表后，大多数主流浏览器也于当年年底支持该标准。此后，凭借着多路复用、头部压缩、服务器推送等优势，HTTP/2 得到了越来越多开发者的青睐。不知不觉的 HTTP 已经发展到了第三代，鹅厂也紧跟技术潮流，很多项目也在逐渐使用 HTTP/3。本文基于兴趣部落接入 HTTP/3 的实践，聊一聊 HTTP/3 的原理以及业务接入的方式。
阅读全文
摘要：合适的平台框架往往能够给混合应用的开发，带来事半功倍的效果。本文将向你介绍目前6种最为实用的开发框架。
众所周知，根据使用场景的不同，我们往往需要针对智能手机、平板电脑以及可穿戴设备等不同平台，开发相应的应用。如果为每一类应用都去编写独特的程序代码的话，不但耗时，而且无法实现代码的重用。因此，我们需要引入混合应用开发的机制。
通常，我们可以使用各种现成的框架，去编写一个混合应用，然后将其存储在原生的容器中，以实现在不同的平台上，部署此类原生应用。可见，合适的平台框架，能够给混合应用的开发，带来事半功倍的效果。下面，我将向你介绍目前6种最为实用的开发框架。
阅读全文
摘要：微服务作为云原生时代下一种开发软件的架构和组织方法，通过将明确定义的功能分成更小的服务，并让每个服务独立迭代，增加了应用程序的灵活性，允许开发者根据需要更轻松地更改部分应用程序。同时每个微服务可以由单独的团队进行管理，使用适当的语言编写，并根据需要进行独立扩缩容。但微服务同样也并非“银弹”，在带来如此多的优势的同时，逐渐膨胀的微服务数量也为系统带来了空前的复杂度，服务之间错综复杂的调用、协作关系如同一层迷雾笼罩在系统之上，借助 Trace、Log、Metric 三驾马车我们的系统具备了一定的可观测性，但所能得到信息是标准化且固定的，往往不能够满足复杂场景下的观测需求，比如微服务引擎 MSE（Microservices Engine）中的微服务治理功能模块为用户用好微服务提供了诸多帮助，但其中的很多功能，比如全链路灰度、无损上下线等会涉及多个应用，且所涉及的信息又不被标准的可观测系统覆盖。而微服务洞察通过动态的信息采集能够填补这其中的一部分空缺，更好地满足这些微服务场景的观测需求，同时也将他们纳入到标准的观测体系中来。
阅读全文
摘要：写软件和造楼房一样需要设计，但是和建筑行业严谨客观的设计规范不同，软件设计常常很主观，且容易引发争论。
设计模式被认为是软件设计的“规范”，但是在互联网快速发展的过程中，也暴露了一些问题。相比过程式代码的简单与易于修改，设计模式常常导致代码复杂，增加理解与修改的成本，我们称之为 “过度设计”。因而很多人认为，设计模式只是一种炫技，对系统没有实质作用，甚至有很大的挖坑风险。这个观点容易让人因噎废食，放弃日常编码中的设计。
本文将深入探索如下问题：
为什么长期来看，设计模式相比过程式代码是更好的？
什么情况下设计模式是有益的，而什么情况下会成为累赘？
如何利用设计模式的益处，防止其腐化？
阅读全文
摘要：1.说说进程和线程的区别？ 进程是程序的一次执行，是系统进行资源分配和调度的独立单位，他的作用是是程序能够并发执行提高资源利用率和吞吐率。由于进程是资源分配和调度的基本单位，因为进程的创建、销毁、切换产生大量的时间和空间的开销，进程的数量不能太多，而线程是比进程更小的能独立运行的基本单位，他是进程的
阅读全文
摘要：1.你们为什么使用 mq？具体的使用场景是什么？ mq的作用很简单，削峰填谷。以电商交易下单的场景来说，正向交易的过程可能涉及到创建订单、扣减库存、扣减活动预算、扣减积分等等。每个接口的耗时如果是100ms，那么理论上整个下单的链路就需要耗费400ms，这个时间显然是太长了。 如果这些操作全部同步处
阅读全文
摘要：从基础的角度看，设计模式是研究类本身或者类与类之间的协作模式，是进行抽象归纳的一个很好的速成思路。后面阅读设计模式后，为了加深理解，对相关图片进行了描绘和微调。从技术的角度已经有很多好的总结，本文会换一种角度思考，既然设计模式研究的是类与类的关系，我们作为工作的个体，一些工作中的策略是不是也可以进行类比，可以更好地去思考这些模式？答案是肯定的。
阅读全文
摘要：导读：对于错误码的设计，不同的开发团队有不同的风格习惯。本文分享阿里文娱技术专家长统对于错误码的看法，希望从错误码使用的不同场景讨论得到一个合理的错误码规约，得到一个面向日志错误码标准和一个面向外部传递的错误码标准。
阅读全文
摘要：日常开发工作中，有时候你是否发现写代码时 6 到飞起顺风顺水，但涉及到需求跟进，会议参与，与人沟通，目标制定等工作场景时，总是不得章法，出现表达不清楚，抓不住重点，琐事包围无法脱身，沟通过程低效等情况，如果有，很显然此时的你需要关注到工作效率的问题。本文尝试从多个方面做一些归纳总结，可能给你带来一些意识和思维上的启发。
阅读全文
摘要：对于前端领域的开发者来说，“学不动了”虽然更多是一种调侃，但也真实地反映出了他们面对频繁出新的前端技术时又爱又恨的心情。在经历了移动互联网的大爆发后，前端领域的边界不断扩张，新技术、新概念、新框架层出不穷。这在一定程度上迎合了开发者喜欢追踪热门框架和技术最新发展的天性，但同时也带来了新问题。热门框架那么多，到底该选哪个？新技术引入并非毫无代价，一味追求新技术是不是合理？最火、最流行的技术一定适合你所在的团队吗？
在大前端领域，我们已经看到了太多技术风口，关于如何做好前端技术选型这件事，我们希望能从不一样的视角聊一聊。为此，InfoQ 近期采访了阅文集团技术专家、前百度 T8 资深研发工程师彭星，谈谈他对目前大前端发展趋势和架构演进的理解，并总结了他在技术方向选择和方案选型上的经验，希望能给大家提供一些参考。另外，彭星是 GMTC 全球大前端技术大会（北京站）2020 大前端架构演进专题的出品人，该专题将通过解读行业具体实践案例明晰前端架构演进的路径和未来方向，感兴趣的同学可以关注。
阅读全文
