沉潜飞动

你好，我是看山。前面咱们聊了架构的演进过程，提到单体架构、SOA 架构、微服务架构、无服务架构。整个过程如下图：目前无服务架构还未成熟，只能满足一些简单场景。所以大家在设计软件架构时，首选还是微服务架构。然后我们又聊了聊如何把单体架构改造为微服务架构，推荐采用绞杀模式，一步一步的实现系统微服务化。在这个过程中，我们会碰到微服务架构的一个大坑：分布式错觉，即将分布式当成了微服务的全部（充要条件）。原因出现分布式单体的主要原因在于，只是用进程间的远程调用替换进程内的方法调用。从上图可以看出，.

从单体架构、SOA架构，到微服务架构，再到容器化、无服务架构，我们的选择很多，没有必要非在一棵树上吊死。

该图片由daschorsch在Pixabay上发布你好，我是看山。本文收录在《一个架构师的职业素养》专栏，日拱一卒，功不唐捐。定义策略模式，英文全称是 Strategy Design Pattern。在 GoF 的《设计模式》一书中，它是这样定义的：Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary in..

你好，我是看山。从单体架构到分布式架构，从巨石架构到微服务架构。系统之间的交互越来越复杂，系统间的数据交互量级也是指数级增长。作为一个系统，我们要保证逻辑的自洽和数据的自洽。数据自洽有两方面要求：抛开代码，数据能够自己验证自己的准确性，也就是数据彼此之间不矛盾所有数据准确且符合期望为了实现这两点，需要实现数据的一致性，为了实现一致性，就需要用到事务。需要注意一下，本文所设计的数据一致性，不是多数据副本之间保持数据一致性，而是系统之间的业务数据保持一致性。本地事务在早期的系统中，我们可.

个人认为单例模式是设计模式中最简单也是最常用的一种，是对有限资源合理利用的一种方式。这个模式看似简单，但是其中蕴含了关于并发、类加载、序列化等一系列深层次的知识，如果理解不够深，就有可能在高并发时遇到难以预期的异常，或者会造成资源浪费。

随着微服务架构的普及，线上服务越来越多，随之而来的就是部署越来越频繁；随着互联网行业的兴旺，产品迭代的频率也是越来越快，服务上线速度逐步提升。有上线、有部署，就有风险。有风险，就对业务有影响，然后就有了一系列减少这种风险的部署方案：蓝绿部署、金丝雀发布（灰度发布），也有适应产品迭代频率的AB测试。

以提供用户基于云的各种服务为主，共包含三个层次：其一是 Software as a Service 软件即服务，简称 SaaS ，这层的作用是将应用主要以基于 Web 的方式提供给客户；其二是 Platform as a Service 平台即服务，简称 PaaS ，这层的作用是将一个应用的开发和部署平台作为服务提供给用户；其三是 Infrastructure as a Service 基础设施即服务，简称 IaaS ，这层的作用是将各种底层的计算（比如虚拟机）和存储等资源作为服务提供给用户。

在实际开发过程中，经常会需要定义一个文件，用于存储一些常量，这些常量设计为静态公共常量（使用 public static final 修饰）。这个时候就出现两种选择：在接口中定义或在类中定义常量。

一直听别人说HTTP长连接，只知道长连接比短连接更节省资源、更快捷，但是并不真的知道原因。知其然不知其所以然，对于技术来说，这种状态是比较危险的。所以，还是要挖一下原理，即使挖的比较浅，也要迈出这一步。HTTP是应用层协议，传输层使用的是TCP协议，网络层使用的是IP协议。

微服务的优势众多，在现在如果有谁没有听过微服务架构，可以从这里了解一下。本文主要聊一聊是否值得花时间将单体架构重构为微服务架构？微服务架构是一种架构风格，专注于软件研发效能，主要包括单位时间内实现更多功能，或者软件从想法到上线的整个持续交付的过程。在当前的互联网环境中，业务变化迅速，也促使了微服务架构的普及。这种架构迫使团队迅速反应，快速实施，在方案没有过期之前已经上线运行，经受市场考察和考...

什么是微服务？我所理解的微服务，就六个字：“高内聚，低耦合”。没错，就是这个在软件开发过程中被反复提到的六个字，各类设计模式、架构设计、从入门到放弃等各种书中总会提到，从初级到高级到骨灰级程序员、架构师挂在嘴边的也是这六个字。只不过，在微服务概念之前，这六个字被用在类、模块、组件上，微服务则是将它放在服务上。

目前很多互联网公司都采用微服务架构，微服务的优点和缺点被反复说到，这里不在重复赘述，只结合工作中的一些实践，说说要用微服务要注意的点，厚颜写做编程范式，其实就是一些技巧而已。

你好，我是看山。本文源自并发编程网的翻译邀请，翻译的是 Jakob Jenkov 的 《软件架构》 中关于事件驱动的内容，虽然是 2014 年的文章，但是从软件架构层面上，并不过时。以下是正文。事件驱动架构是一种系统或组件之间通过发送事件和响应事件彼此交互的架构风格。当某个事件发生时，组件A不直接调用组件B，而只是发出一个事件。组件A不知道哪些组件监听并处理这些事件。事件驱动架构可以在进程内和进程间使用。比如，GUI框架中会大量使用事件驱动。【译者注：目前很多系统采用微服务架构，事件驱动使用的更.

本文源自并发编程网的翻译邀请，翻译的是 Jakob Jenkov 的 《软件架构》 中关于缓存技术的内容，虽然是 2014 年的文章，但是从软件架构层面上，并不过时。缓存缓存是一种加速数据查找（数据读取）的技术，直接读取本地缓存的数据，而不是从数据源读取数据，数据源包括数据库、其他远程系统。缓存是比源数据更靠近使用方的一块存储空间，可以更快的读取操作。缓存的存储介质一般是内存或磁盘，很多时候会选择内存作为缓存介质，但是内存缓存会在系统重启时丢失数据。在软件系统中，数据缓存存在多层缓存级别或多.

短链服务的鼻祖是 TinyURL，是最早提供短链服务的网站，目前国内也有很多短链服务：新浪（t.cn）、百度（dwz.cn）、腾讯（url.cn）等等。不得不问一句，为什么要用短链？这个问题的另外一层意思是，短链服务有必要存在吗？套用万金油答案：存在即合理。短链服务存在的合理性我们先说说短链服务存在的合理性。短链唯一的一个优点是短。微博的早期用户都知道，每条微博只能限制在 140 个字以内，如果想要分享一个链接，就需要减少描述的文字。同样，如果想要在营销短信中放入一个链接，就需要考虑成本问题

用了 Git 多年，优势和挑战都是深有体会。话不多说，直接上问题：如何在足够规模团队中高效使用 Git 管理代码？继续不多话，直接上答案：分支管理。Git 的分支管理有很多实践，有些是从 SVN 类的集中式版本管理工具继承的，有些是根据 Git 自己的特性总结的，目前市面上比较有名的三种 Git 分支管理模型是：TrunkBased：主干在手，天下我有。所有代码都往主干上招呼，发版也只用主干。GitFlow：严谨、规范、难用，主要是记不住该往哪个分支合并了。AoneFlow：前两种都不行，那

在 微服务的基建工作 中提到过，在云原生、微服务时代，如果还是手动修改服务地址，是几乎不可完成的工作，需要一种机制完成自动上报和获取服务地址的支撑组件，可以保障服务的快速上线和下线，这就是服务注册/发现组件。为了表述方便，从系统规模定义几个阶段：- 巨型应用架构时期：很多应用都是一个巨型服务，一个应用包含所有功能，部署在小型机和大型机上，或者直接部署在物理服务器上。- 单体架构时期：应用...

微服务的出现是为了研发效能的提升：相同的人数可以处理更多的需求、维护更多的产品，可以更快的交付产品。基于这点，微服务的基础组件，就从解放人力，减少人为失误出发。

在《微服务架构下的数据一致性：概念及相关模式》中介绍了在微服务中实现数据一致性的三种方式，包括可靠事件模式、业务补偿模式、TCC模式。本文重点说一下可靠事件投递。 1. 可靠事件模式可靠事件模式属于事件驱动架构，微服务完成操作后向消息代理发布事件，关联的微服务从消息代理订阅到该事件从而完成相应的业

从2014年开始，微服务逐渐进入大家的实现，被认为是下一代实现信息化的有效手段。设计到系统，其中绕不开的就是数据一致性，从本地事务，到后来的分布式事务，都能够有效的保证数据一致性。但是在微服务架构中，这两种方式都不是最好的选择。1. 使用本地事务和分布式事务保证一致性在传统的单击应用中，最简单、最直接、最普遍的会使用一个关系型数据库，通过关系型数据库的事务保证数据的一致性。这种事务有四个基本要素：A

ResourceManager（RM）负责跟踪集群中资源使用情况，调度应用程序（比如MapReduce作业）。在Hadoop 2.4之前，ResourceManager存在单点故障，需要通过其他方式实现HA。官方给出的HA方案是Active/Standby两种状态ResourceManager的冗余方式，类似于HDFS的HA方案，也就是通过冗余消除单点故障。

Hadoop文件存储的基础是HDFS(Hadoop Distributed File System)，HDFS的实现依赖于NameNode和DataNode，DataNode用来存储具体数据，NameNode用来管理多个DataNode中分别存储的是什么。理解起来也不难，因为HDFS是分布式的文件系统，也就是有很多机器用来存储数据，一个大文件可能分布在多个机器上，也可能是一台机器上，具体分布在哪些或哪个机器上，主文件

hadoop官方提供了两种HDFS的HA配置方案，两种方案殊途同归，但是需要的钱、精力和技术不同。如果对HDFS架构熟悉的话，就应该知道，NameNode通过FsImage和EditLog两个文件管理DataNode的数据，Secondary NameNode会定期合并EditLog，以减少NameNode启动时的安全检查。EditLog文件存储的是对文件的一条条的操作，也就是说，只要保证有另外一个NameNode的

YARN的基本思想是将资源管理和作业调度/监控的功能分为独立的守护进程。这样就出现了一个全局的 ResourceManager（RM） 和每个应用程序的 ApplicationMaster（AM）。应用程序可以是一个job作业或者一组job作业的有向无环图（DAG）。ResourceManager负责系统中的所有应用程序的资源分配。NodeManager负责每台机器中容器代理、资源监控（cpu，内存，磁盘，网络），并

在一些系统中，会有对某些任务状态进行跟踪，如果任务失败需要重新执行任务。本文主要是针对这种请求提出解决方案，因为时间原因，方案还没有在代码中实现。但是经过和朋友的推演，是目前能想到的比较有效的方案了。鉴于本人才疏学浅，如果有某位大神有更好的解决方案，请一定不吝赐教，感谢不尽。。。