微服务架构大成以来，业界持续有声音在质疑微服务架构的弊病，时不时的有曝出某某大厂回归了单体架构。今年（即2023年）5月份，又曝出亚马逊一团队抛弃微服务架构回归单体架构后，成本降低90%，引发业内热议。正于此时Spring Modulith更新到了0.6版本。这个孵化于Moduliths项目并且现已纳入Spring Boot 体系的框架的愿景是要将单体架构的框架水平拉升到微服务架构Spring Cloud的层次，让架构师们在做架构选择的时候，能基于真正需求去考量，而不是基于框架先进性。 抛开微服务的优点先不说，我所在的公司也在成本上苦微服务架构久矣……因此，我抽空通读了官方的简介、文档和相关示例代码，以期能盼来解药，结果只能说还差点意思……大家怀念单体架构主要是因为单体架构开发方便，部署方便，然后性能高，但是带来的缺点是事实上的紧耦合，无论再好的规范和设计，也都会随着成员的增多、时间的流逝、紧急需求的响应，导致代码纠缠不清，一团乱麻；而微服务架构带来的是松耦合，独立发布，水平扩展，但是会导致部署架构复杂，基础设施成本、运维成本飙升……Spring Modulith的解法是用单体架构 ...

在一个企业组织里，科技部门不免需要回答科技投入到底产出了什么，科技投产效能是高是低，要回答这个问题不是一个简单的事情。特别是当CEO有这个疑问的时候，通常意味着他对科技的投入产出已经产生了怀疑，定性的产出描述，“形成了XXXX技术能力，提升了XXXX技术水平”，都无法消除他的怀疑。 在一家科技企业里，科技投入通常是在做三方面工作：（一）科技产品的研发；（二）核心技术能力的建设；（三）基础的IT支撑。 科技产品的研发科技产品研发投入带来的直接产出是可供销售的软件系统或者支撑业务运营的软件平台。这两部分可直接与市场收入挂钩。但当市场销售不佳，收入较少时，是否就意味着科技产品的研发产出较差呢？我觉得在投资人的角度来看，这个结论是正确的，但是在公司治理中去看却不竟然。因为只要研发部门按照产品设计部门的设计和时点完成了产品研发，那就代表着科技部门履行了职责，后续市场表现不佳，通常是产品设计或销售环节出了问题。因此我觉得衡量科技产品的研发产出应复合收入和需求实现情况来评价。收入要考虑滞后性，将后续一定时段内的收入框算进来。产品研发效能 = （研发相关收入+需求实现率 X 系数）&# ...

公司网络不支持IPv6，Drive Client使用6690 TCP端口，没有IPv4地址，通过QC连接速度太慢。刚好有台有公网IPv4的云主机，简单的使用NPS实现了TCP隧道转发，记录一下步骤，供参考。 服务端/公网IP云主机 使用docker部署NPS服务端。如果在启动的时候报错提示缺少配置文件，那就根据提示在配置文件目录下，新建对应的文件。docker pull ffdfgdfg/npsdocker run -d --name nps --net=host -v <本机conf目录>:/conf ffdfgdfg/nps 修改nps.conf文件http_proxy_port = 7001 域名代理https代理监听端口,不用可以随便填一个https_proxy_port= 7002 域名代理http代理监听端口,不用可以随便填一个public_vkey = 客户端以配置文件模式启动时的密钥，设置为空表示关闭客户端配置文件连接模式web_username= web界面管理账号web_password= web界面管理密码web_port = 7003 ...

最近看几家HIT厂商在说自己遵循了openEHR标准规范去做了一些应用，包括个人健康档案、集成平台、临床数据仓库、电子病历等等，不一而足。那些厂商到底是应用openEHR解决了一些现实问题呢，还是在整宣传噱头呢？我基于自己的理解，谈一谈openEHR到底适合干什么。 openEHR的起源EHR是电子健康档案的英文缩写，openEHR原本就是一套开源的电子健康档案规范，它是发源于欧洲的GEHR（Good Europe Health Record），最开始的目的是支撑欧洲健康远程信息通讯。上个世纪末，有人基于GEHR的研究成果，提出了openEHR的概念，期望建立一个开源的电子健康档案规范。后来专门的openEHR机构成立了，openEHR机构的主要是目标是通过研究临床需求、建立标准与实施软件，实现开放的、支持互操作的健康处理平台，以加快促进高质量的EHR的发展。经过了十几年的发展，到了2010年后openEHR被引入了中国， openEHR规范概述 openEHR最核心的概念就是RM \ AM,以及EHR、COMPOSITION、SECTION、ENTRY四类对象。 先讲EHR、CO ...

最近一年工作发生很大变化，从技术、研发管理领域转战到了更偏向技术管理、产品管理领域，视角发生了很大变化，也有了很多感悟，正好很久没写文章了，于是总结总结，聊聊在软件企业里如何去做好研发管理、技术管理、产品管理。 产品管理产品管理不同于产品经理做的事。产品经理的工作是致力于打造出一款好的软件产品。产品管理是更高层次的事情，是在企业层面去对所有的产品进行管理，是同时对这家企业的所有产品负责。 做好产品的管理最本质的是要参透在产品到底是什么，产品管理到底要去管什么。有意思的是从企业视角去看产品，与产品经理眼中看到的产品并不一致。之前有产品经理过来诉苦，说我的产品多么好多么牛，结果公司高层却不认可，最后还被砍了，CEO真是SB。其实出现这种现象的原因就是因为他不理解在企业看来产品是什么。 关于产品产品首先是商品。产品被创造出来的目的就是为了销售。所以产品的好坏比较关键的点在于他是否卖的好，而并不在于他是否优美、先进。不可否认的是现实中，特别在 ToB行业很多卖的好的产品并不先进。 产品是以为公司取得收入为目的。产品既然是商品，那么它生来就背负这个使命。产品一定要取得收入，可以是短期收入，也 ...

Domain-driven design并不是一个新鲜的东西，从 2004 年Eric Evans提出这个理念以来，十几年间时不时就有一股DDD的热潮，近几年随着微服务的大行其道，DDD又成了宠儿。但终究逃不过雷声大雨点小。 领域驱动设计最根本的思路是一套自上而下的设计方法，即从要解决的问题领域或系统目标出发，由业务和架构专家一起，对复杂的业务场景和关联性进行分组归类，形成一个一个相对单一职责的子领域。子领域和子领域之间要有明确的界限。在子领域内部，再通过业务上的模型去归类对应的属性和行为。 从设计思想上看，我非常赞同自上而下的架构设计理念，也在不断践行。但今天在技术圈里流传的DDD早已超出了上述的定义，而变成了一套以充血模型为基础，围绕聚合根，并通过门面代理、分离查询、事件传播等手段的软件架构方法。通过这种构建，想达成三种目的： 统一语言：业务与技术统一 让行为回归到实体中去 降低传统service层的复杂度 我所不采纳的即是这样一种“术”，有三个主要原因。 行为是变化的，对象的表达却是几乎不变的，将变化的与不变的聚合在一起，违反了动静分离的原则。 软件实现的是策略，最终想 ...

SSE，全称Server-Sent Events，作为一种半双工的前后端通信方式，由于实现方式简单、轻量，在后端向前端的主动推送场景中具备很好的应用效果，笔者最近在一个项目中多有使用，过程中也是查阅了不少资料和文档，也有所感悟，在此将整体做一次综述。这是一篇系列文章，共分三篇，这是第三篇。 详解Spring 5 Server-Sent Events(一) 基本介绍 详解Spring 5 Server-Sent Events(二) WebMVC 详解Spring 5 Server-Sent Events(三) WebFlux 引言Spring WebFlux framework 5.2.0基于Reactive Streams api，使用事件循环计算模型来实现异步Java Web应用程序。这样的应用程序可以运行在非阻塞的web服务器上，如Netty 4.1和Undertow 1.4，以及Servlet 3.1+容器，如Tomcat8.5和Jetty 9.3。 概述在WebFlux中实现发送事件，需要以下几步： 创建一个controller类并用@RestController注释标记 ...

SSE，全称Server-Sent Events，作为一种半双工的前后端通信方式，由于实现方式简单、轻量，在后端向前端的主动推送场景中具备很好的应用效果，笔者最近在一个项目中多有使用，过程中也是查阅了不少资料和文档，也有所感悟，在此将整体做一次综述。这是一篇系列文章，共分三篇，这是第二篇。 详解Spring 5 Server-Sent Events(一) 基本介绍 详解Spring 5 Server-Sent Events(二) WebMVC 详解Spring 5 Server-Sent Events(三) WebFlux 引言Spring WebMVC Framework 5.2.0基于Servlet 3.1，需要中间件能支持Servlet 3.1 API，比如**Tomcat 8.5 **和 Jetty 9.3。 概述在WebMVC中实现发送事件，需要以下几步： 创建一个controller类并用@RestController注释标记它 创建一个接受Http GET请求的方法，该方法返回一个SseEmitter对象 在另一个线程中，获取这个SseEmitter实例，并 ...

SSE，全称Server-Sent Events，作为一种半双工的前后端通信方式，由于实现方式简单、轻量，在后端向前端的主动推送场景中具备很好的应用效果，笔者最近在一个项目中多有使用，过程中也是查阅了不少资料和文档，也有所感悟，在此将整体做一次综述。这是一篇系列文章，共分三篇，这是第一篇。 详解Spring 5 Server-Sent Events(一) 基本介绍 详解Spring 5 Server-Sent Events(二) WebMVC 详解Spring 5 Server-Sent Events(三) WebFlux 引言在性能可接受的web应用程序中，没有简单、通用的方法来实现服务端到客户端的异步通信。 HTTP是B/S中的一种请求-响应协议。客户端（通常是浏览器）向服务端提交请求，服务端向客户端返回一个响应。服务端只能向发出请求的客户端发送响应。在HTTP协议中，客户端是消息交换的发起者。 在某些情况下，需要服务端成为消息交换的发起方。实现这一点的方法之一是允许服务端将消息推送到支持发布/订阅模式的客户端中。客户端从服务端订阅消息，服务端向许多订阅的客 ...

Spring 5支持的WebFlux对于全局异常的捕捉与以前的WebMVC框架有了不同，不能靠@ControllerAdvice或@RestControllerAdvice打天下了。目前国内的资料比较少，而且语焉不详，下面我将处理方式分享出来，文末有我的项目代码供参考。 核心要点是要继承AbstractErrorWebExceptionHandler这个WebFlux下的全局异常处理类，然后重写getRoutingFunction。 需要注意的是AbstractErrorWebExceptionHandler中的构造方法中未对messageWriters进行初始化，源码如下： private List<HttpMessageWriter<?>> messageWriters = Collections.emptyList(); messageWriters是用于最终生成response body的，所以我们必须在实现类中对它进行初始化： public GlobalErrorWebExceptionHandler(ErrorAttributes errorA ...