Posts

今年3月随着Go 1.18版发布，引入了一个重大的语言特性：泛型编程。这个特性在发布前引起了一定的争议。崇尚少即是多的一边认为这个特性不是很必要，应该谨慎引入。另一边则认为这是语言必不可少的特性。最后Go的泛型还是如期而至 泛型编程在其他编程语言也遇到了不同的问题，比如在Java 1.0时是没有引入泛型编程支持，到了Java 1.5的时候引入了泛型，但由于引入时间过晚，有大量的标准库和第三方库无法支持，Java选择了妥协采用间接的类型擦除方式来实现泛型编程，导致泛型的使用复杂度增加，同时场景受限。而C++比较明智，一开始就支持泛型，所以在C++ STL标准库里面大量的算法都是采用泛型实现，整个语言体系中泛型占据了核心位置 学习一个语言的特性可以参考其他语言同样的特性，这样就可以了解这个语言特性实现是否设计合理，是否优雅，存在哪些局限性 语言版本： C++11 Java 11 Go 1.18 1. 泛型函数 泛型函数用来支持当一个算法用在多种数据类型上，为了避免重复的定义函数，而用泛型函数来支持 两个数据进行取小操作 //C++ template <class T> T min(T a, T b){ return a < b ? a : b; } //Java不支持 //Go func Min[T int|float64](a, b T) T { if a < b { return a } else { return b } } 2. 泛型函数-显示特化 当泛型函数用来支持一个算法用在多种数据类型上，但在某个类型数据上泛型函数的实现不适合该类型，那么我们可以显示特化该类型的实现算法 /C++独有 template<> string min<string>(string a, string b){ return a.size() < b.size() ? a : b; } 3.泛型类 泛型类的目的是创建一个集合类型，里面的各种数据类型可以进行相同的操作，泛型类避免了多个数据类型的重复定义 ...

最近因为未控制饮食，以及家附近游泳池关闭，导致体重持续上升，已经到了自己难以忍受的状态，148.5。 一直知道有一种可能比较健康的生活方式，轻断食，但一直不知道怎么实践，通过搜索发现有部记录片《进食 断食 长寿》，介绍了轻断食的理念。决定先尝试一下正常断食，计划断食4天半，每天吃一些蔬菜汤，维生素，卡路里在200左右，完成后采用5+2轻断食法维持健康。 4月开始 第一天 23号晚上暴饮暴食后，不再进食，24号白天中午，未感觉任何饥饿感，可能是头天晚上吃太多了，出去溜达溜达，中午也没午觉，下午继续办公，办公后进行骑行锻炼1.5小时。晚上回来感觉头有点晕，吃了半碗饭+一小份莴笋烧兔子，补充了一颗维生素，肚子咕咕叫，后面整体正常。晚上睡觉质量变差，睡眠变浅。网上查询是因为身体激素变化的原因，断食期间睡眠会出现没有以前好的状况。 第二天 25号早晨体重145.5，没有饥饿感，工作到中午一样没有多少睡意，中午出去溜达一圈。下午工作到16点时，困意来袭，小眯了一会儿。进行骑行锻炼1.7小时，感觉力气没有昨天多。晚上自制蔬菜+西红柿汤，大概卡路里在200以内，补充一颗维生素。 肚子继续咕咕叫，并伴有轻微腹泻，持续时间一整夜。晚上睡眠还是变浅，醒来几次。 第三天 26日早晨体重143.5斤。无头晕感觉，但觉得力气不足。喝水，补充一颗维生素。腹泻状态暂时消失。今天工作比较忙，晚上回家感觉心跳加快，有些不适，怕影响健康，停止断食，开始正常晚餐。 后续开展5+2轻断食+运动，5.9号测量体重为142斤，正常开始降低体重。 7月期间 加大运动量，体重降到130以下，身体并无不适 9～10月期间 由于疫情运动量减小，加强了断食间隔，断食日整天不吃。体重维持到126左右。但出现营养不良型脱发。在10月下旬恢复正常饮食，脱发继续。 11月初脱发减少恢复正常。考虑轻断食太重可能影响健康。开始恢复正常饮食，同时加强运动消耗。体重126左右。

上一篇文章《理解响应式编程（reactive programming)》我们谈到响应式编程四个核心概念： 发布者(The Publisher): 发布者就是数据的生产者，这个是为系统生产数据的组件，这里的服务B就是一个发布者，他收到服务A的请求后就开始生产数据。 订阅者(The Subscriber): 订阅者订阅发布者生产的数据。这里服务A就是订阅者，他订阅来自服务B的数据。 订阅过程(The Subscription):订阅过程是一份服务之间的合约（contract)，它被用于订阅者获取数据，或者取消订阅。 处理者(The Processor):处理者是一个响应式实体，他能够消费发布者的数据，并进行再加工，然后发布自己的数据，上面的例子并未体现这层逻辑。举个例子，排序处理者，他可以作为订阅者获取发布者的随机序数据，然后进行排序，然后作为发布者生产出排序后的数据。 一个典型的响应式交互如下： 订阅者和发布者签订订阅契约(Publisher.subscribe),一旦契约签订完成，订阅者向发布者请求数据(Subscription.request),发布者准备好数据后传输数据给订阅者(调用订阅者onNext)，订阅者再次请求新数据(request)，直到发布者告诉订阅者数据已经发送完成(onComplete)，本次契约完成。 Reactive REST Appplication 现在我们使用WebFlux开始构建一个简单的响应式应用. 使用一个简单的领域模型-Employee 使用RestController返回发布者生产的数据 使用WebClient构建订阅者获取发布者数据 WebFlux Maven依赖如下： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-webflux</artifactId> </dependency> 发布者（Publisher） WebFlux底层使用Project Reactor，所以我们这里使用Project Reactor的命名来介绍。 发布者有两个类型： Mono类型表示生产0个或者至多1个数据 Flux类型表示生产多个数据 示例代码分为三层分别是： controller-获取REST请求，并返回订阅数据 model-包含Employee领域模型 repository-构建内存数据库（采用HashMap) controller: 可以看到方法返回类型为Mono或者Flux，表示生产者会生产对应类型个数的数据 @RestController @RequestMapping("/employees") public class EmployeeController { private static final Logger logger = LoggerFactory.getLogger(EmployeeController.class); private final EmployeeRepository employeeRepository; public EmployeeController(EmployeeRepository employeeRepository) { this.employeeRepository = employeeRepository; } @GetMapping("/{id}") private Mono<Employee> getEmployeeById(@PathVariable String id) { logger.debug("getEmplyeeById controller get called"); return employeeRepository.findEmployeeById(id); } @GetMapping private Flux<Employee> getAllEmployees() { logger.debug("getAllEmployees controller get called"); return employeeRepository.findAllEmployees(); } @PostMapping("/update") private Mono<Employee> updateEmployee(@RequestBody Employee employee) { return employeeRepository.updateEmployee(employee); } } model： 很简单的领域模型Employee包含id和name两个字段 ...

过去十年互联网用户数呈指数级增长，各类网络服务访问数量也随之持续增长。为了应对持续增长的访问需求，各种技术被重新赋予了新的活力。微服务，DDD，响应式编程等技术被重新改进用于应对以上问题。本文着重讨论响应式编程背后的原理，帮助读者理解并应用于实际的开发中。 响应式宣言 说到响应式编程首先要引入一个概念响应式系统（Reactvie Systems)。回到2013年Jonas Boner领导的开发团队提出了响应式宣言，其中定义了响应式系统一系列核心原则.主要描述了该系统应具备灵活性，松耦合以及可扩展性.原则描述了响应式系统的基础特性： 可响应性：一个响应式系统应提供快速和一致的响应时间，以及一致的服务质量 可复原性：一个响应式系统在随机失败的情况下，通过复制和隔离能力保持响应 可伸缩性：一个响应式系统在不可预测的负载下，通过经济的可扩展性保持响应 消息驱动：系统组件之间应通过异步消息机制进行通信 响应式编程要解决什么问题 在非响应式同步调用的系统中两个服务是怎么调用的呢？假设我们有A，B，2个服务，当服务A调用服务B后（request），服务B开始处理收到的请求，这个时候服务A的线程会被阻塞住（idle），等待服务B处理完成后返回响应给服务A（respond），这时服务A线程被唤起继续处理接下来的逻辑。 这是我们常用的同步调用方式，他最大的问题是会使资源经常处于idle状态，没有充分利用我们的资源，对资源浪费很大。例如服务A调用服务B的线程在调用后就被阻塞住，不能做其他的事情，直到服务B响应为止。我们知道系统的线程要占用CPU周期，内存等硬件资源，并且极其有限。 那么响应式编程的目标就是解决资源浪费问题，最高效地使用资源。这里我们看到服务A线程调用服务B后，并未等待服务B处理完成，便开始处理其他逻辑，所以服务B的单个线程可以不断调用服务B。那么服务B也可以不间断的收到大量的请求进行处理，这里A，B两个服务都高效的利用了资源。 响应式编程背后的原理 这怎么实现呢？当服务A调用服务B的时候，AB服务之间建立了一个订阅通道，通道建立好以后，服务A线程就去处理其他逻辑，等服务B处理完请求准备好数据后，便会通知服务A数据已经准备好了，这个时候服务A会有一个独立的线程池去获取服务B的数据，这样就实现了同步调用/异步响应的调用方式。 这里有几个响应式编程重要的核心概念： 发布者(The Publisher): 发布者就是数据的生产者，这个是为系统生产数据的组件，这里的服务B就是一个发布者，他收到服务A的请求后就开始生产数据。 订阅者(The Subscriber): 订阅者订阅发布者生产的数据。这里服务A就是订阅者，他订阅来自服务B的数据。 订阅过程(The Subscription):订阅过程是一份服务之间的合约（contract)，它被用于订阅者获取数据，或者取消订阅。 处理者(The Processor):处理者是一个响应式实体，他能够消费发布者的数据，并进行再加工，然后发布自己的数据，上面的例子并未体现这层逻辑。举个例子，排序处理者，他可以作为订阅者获取发布者的随机序数据，然后进行排序，然后作为发布者生产出排序后的数据。 背压机制(Backpressure Mechanism) 前面说到响应式编程包含发布者生产数据，订阅者订阅数据，很自然想到当发布者生产数据的速度和订阅者消费数据的速度不匹配的问题，特别是快于订阅者能消费数据的速度，这时系统就是出现问题，订阅者就会被过量的数据淹没。 响应式编程是为了高效的利用系统资源，总不能把系统服务打垮了吧。这时我们在设计系统的时候会引入背压机制来控制发布者和订阅者之间的平衡。 一般我们通过三种策略来调控速率： 控制发布者发送数据的速率（推荐） 订阅者使用缓存来存储暂时无法处理的数据 订阅者丢弃所有无法处理的数据 为了达到系统的高效运行，通过背压机制，使发布者和订阅者速率达到平衡，也就是根据消费能力来按需生产和发送数据，生产多少，就消费多少，用前面的A，B服务的例子来说明： 服务A给服务B发送一个request请求1个数据，服务B的生产完成1个数据的时候，就通知服务A（onNext）有个数据就绪了,服务A就以同样的速率处理数据，这样服务B生产速率就被服务A限制，A，B两个服务就工作在同样的速率，这样系统效率达到最佳。 在这里讲完了响应式编程的核心原理，下一篇《使用WebFlux进行响应式编程》会继续深入讨论响应式编程在代码中的实现。

我们常说代码除了满足功能需求以外，还应该满足以后的可读性，可测性，可扩展性，可维护性等。我们常常看到两种类型的团队，一类团队软件开发流程里面只有开发+测试，常常处于加班状态，不断的赶新功能上线。另一类团队有完善的软件开发过程，迭代开发，同行评审，单元测试，自动化测试等。主观觉得第二类团队的代码质量应该比较高，可我们对这两类团队的代码到底怎么样，除了一般常用的sonar，findbugs等静态扫描工具的数据，就没太多的了解。除非深入学习业务逻辑，并剖析源代码。 代码的抽象性，决定了代码以后是否容易扩展，抽象性高的代码易于通过继承的方式进行扩展，抽象性低的代码更容易出现复制-粘贴的扩展方式。代码被别的类依赖多，导致代码不容易变化，反之代码可变性就很高。如果从这两个方面考虑代码的设计，就提供了更多的维度了解团队代码的健康度。 我们以模块为基本单位，统计整个系统每个模块的抽象性和依赖性: 代码抽象性 Nc:模块内类的数量 Na:模块内抽象类和接口的数量 A：代码抽象性 A = Na / Nc 那么这个值的区间是[0,1] 代码依赖易变性 Fan-in:进入的依赖。模块外有多少个类依赖于该模块内部类。 Fan-out:出去的依赖。模块内有多少个类依赖于模块外部的类。 代码依赖易变性： I = Fan-out/(Fan-in + Fan-out) 值区间[0,1] 举个例子: 上图Fan-in=3, Fan-out=1 模块依赖易变性 I=1/(3+1) 如果我们把代码抽象性和依赖性放入到二维坐标轴，x坐标是代码依赖易变性，Y坐标是代码的抽象性。然后在图里面最高抽象性（左上角）到最高抽象易变性（右下角）划一条对角线，这条线叫主道线。 我们在上图可以看到三个区域1.痛苦区 2.无用区 3.主道线区 处在痛苦区的模块里面类的抽象性不足，同时极度的稳定，依赖易变性低。这种模块可扩展性不足因为抽象性低，同时被多个模块依赖，不能轻易改变。如果要扩展这个模块的功能，就会产生大量的复制-粘贴重复代码。有一个例外就是基础工具模块，这类模块的特征就是处于极度稳定，并不需要抽象性，所以这类工具模块处于这个区间是合理的。 处在无用区的模块里面类的抽象性很高，但没有类去使用所以依赖易变性也很高。这个区间的模块包含大量的抽象类和接口，但没有外部模块使用它，所以变成了无用的模块。 结论是我们期望一个系统大部分的模块都处于主道线区，不要偏离主道线太远。如果一个模块的二维坐标到主道线的距离过远比如达到0.5，那么这个模块值得打开深入分析里面的类的抽象性与依赖性是否合理。 这里我写了一个工具可以分析java代码的抽象性与依赖性供参考： GitHub