随笔分类 - 软件工程
摘要：我们在谈数仓之前，为了让大家有直观的认识，先来谈数仓架构，“架构”是什么？这个问题从来就没有一个准确的答案。这里我们引用一段话：在软件行业，一种被普遍接受的架构定义是指系统的一个或多个结构。结构中包括软件的构建（构建是指软件的设计与实现），构建的外部可以看到属性以及它们之间的相互关系。
阅读全文
摘要：“ DDD设计的目标是关注领域模型而并非技术来创建更好的软件，假设开发人员构建了一个SQL，并将它传递给基础设施层中的某个查询服务然后根据表数据的结构集取出所需信息，最后将这些信息提供给构造函数或者Factory，开发人员在做这一切的时候早已不把模型看做重点了，这个整个过程就变成了数据处理的风格 ”——摘 Eric Evans《领域驱动设计》
《领域驱动设计》中的Repository（下面将用仓储表示）层实际上是极具有挑战性的，对于它的理解，也十分重要。本文大部分内容都在众多前辈理论基础上，从一个崭新的领域视觉开始探索，并结合自己的实践感悟进行细致的解析。同时本文不仅仅是DDD前辈的搬运工，也创新提出了仓储实体转移的概念，可以提供给读者思考是否在自己场景中可以用到这种模式。即使读者也对仓储有很深的了解，我也觉得本文会对你有新的阅读体验。
阅读全文
摘要：微服务之间的调用有两种方式，RPC和事件驱动。事件驱动是更好的方式，因为它是松耦合的。但如果业务逻辑是紧耦合的，RPC方式也是可行的（它的好处是代码更简单），而且你还可以通过选取合适的协议（Protobuf gRPC）来降低这种紧耦合带来的危害。
由于事件溯源和事件通知的相似性，很多人把两者弄混了，但它们实际上是完全不同的东西。微服务的数量不宜太多，可以先创建比较大的微服务（更像是服务组合）。
如果你还是不能确定是否采用微服务架构，可以先从“内部微服务设计”开始，再逐渐拆分。
阅读全文
摘要：张建飞是阿里巴巴高级技术专家，一直在致力于应用架构和代码复杂度的治理。最近，他在看零售通商品域的代码。面对零售通如此复杂的业务场景，如何在架构和代码层面进行应对，是一个新课题。结合实际的业务场景，他沉淀了一套“如何写复杂业务代码”的方法论，在此分享给大家，相信同样的方法论可以复制到大部分复杂业务场景。
阅读全文
摘要：商品系统是电商系统最基础、最核心的系统之一。商品数据遍布所有业务，首页、门店页、购物车、订单、结算、售后、库存、价格等，都离不开商品。商品信息要稳定提供至到家供应链的每个节点，所以必须要有一套稳定的、高性能的商品服务体系支撑。
随着京东到家商品业务的快速发展，业务从单一转变为多元化，系统功能设计上也从最初的大而全的功能支持，向微功能、领域化演变。
商品系统也在高可用、高并发的持续冲击下，经历了多个架构版本的演进。最初1.0版本，采用合适简单的设计思路，满足了业务快速迭代上线；随着业务量级的快速增长，针对高可用、高性能的提升，演进出了2.0版本。随后业务复杂度的提升，导致了系统复杂度的提升，为了解决系统复杂度带来的问题，孕育出了3.0商品体系领域建设。
阅读全文
摘要：稳定性保障工作从时间上来说，包括日常业务需求开发时的监控告警配置和开关预留，大促前夕的容量预估、压测、限流、扩容和预热，其实还有一部分，上文未及提及，那便是大促值班。
建议在值班前写一个值班手册，将可能出现的问题，解决方案，需要使用到的工具链接全部罗列清楚，避免值班时手忙脚乱找资料找工具。还有必要的权限申请在值班前申请好。
在大促期间，严阵以待，这个时候需要做到两动，主动关注监控大盘，注意流量变化，监控基础设施指标；被动关注告警，一旦被告警提醒就是有异常情况了，要立刻投入定位解决。
最后，稳定性保障工作是没有尽头的，其重要性不言而喻，但是也要在业务功能与稳定性之间做好权衡，如果稳定性核对的调用流量都超过了业务流量，那么稳定性工作就有点过了，从机器成本、人力成本上都没有这个必要。
本文整理了自己对稳定性保障的认识和理解，可能存在理解有误或者认识不足的情况欢迎指正，也期待更多的学习逐渐修正和完善自己的稳定性相关知识。
阅读全文
摘要：本文作者通过分析微服务的常见优点能解决的问题，提出如何使用单体应用来缓解这些问题，最终指出采用微服务还是单体架构要根据团队实际情况，而不是为了微服务而微服务。作者最后给出建议，中小团队和新型团队，建议采用单体架构，大中型团队，可以采用微服务架构，但要充分权衡。
在 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 实现百花齐放。面对众多技术方案，我们如何做出合理的选择，规避潜在风险，本文将给出一些选型建议，供大家参考。
阅读全文
摘要：作为卓越工程文化的一部分，Code Review其实一直在进行中，只是各团队根据自身情况张驰有度，松紧可能也不一，这里简单梳理一下CR的方法和团队实践。
阅读全文
摘要：“架构制图”这词乍一听似乎有些晦涩，但如果提起“工程制图”，相信绝大部分工科背景的程序员们都不会陌生，甚至还能共同感慨下那些年一起伏在宿舍左手圆规，右手直尺，徒手作图到深夜的日子。
软件工程也是工程，因此传统工程制图的一些基本理论，在软件行业同样适用。但另一方面，软件与实体制造业之间还是有着本质区别，所以在制图方面的需求和方式也大相径庭，无法直接套用。作为软件行业的从业者，你可以完全不懂工程制图，但你不得不懂架构制图 —— 这是任何程序员职业生涯的的必修课。
阅读全文
