手机号码一键登录是最近两三年出现的一种新型应用登录方式，比之前常用的短信验证码登录又方便了不少。登陆时，应用首先向用户展示带有本机号码掩码的授权登录页面，用户点击“同意授权”的按钮之后，应用即可获取到完整的本机号码，从而完成用户的登录认证。在这个过程中，应用只要确认登录用的手机号码是在绑定了此号码的手机上发起的即可认证成功，从这一点来看，它和短信验证码登录并无本质区别，都是一种设备认证登录方式。这篇文章就来捋一下其中的技术门道。

这几年为了保护用户的隐私安全，Android和iOS系统都限制了应用获取本机号码的能力，即使通过某些技术手段获取到了本机号码，这个号码还可能是被篡改的，所以应用直接读取本机号码用于登录是不可行的。那么这些应用是怎么获取到真实的本机号码的呢？答案是电信运营商，手机要打电话、要上网、要计费，运营商肯定能对应到正确的手机号码。国内的运营商就是移动、联通、电信这三家，它们都开放了这种能力。对于在互联网大潮中被管道化的运营商来说，不失为一种十分有意义的积极进取。

手机流量上网的原理

手机号码一键登录是借助手机流量上网来实现，所以先要搞清楚流量上网的原理。

目前网上已有很多关于一键登录的技术文章，但是内容基本雷同，关于获取手机号码的部分，所述都是通过运营商的数据网关能力，语焉不详，对于有追求的技术人来说，难以忍受。这个章节就来介绍下这种从数据网关获取手机号码的能力是如何实现的，因为通信专业知识十分繁杂，我也没有经过专业的学习，大家也不想接触到很多的专业名词，所以这里只保留一些关键的专业名词，尽量以通俗易懂的方式来理清这个机制。

五层网络模型

对网络比较熟悉的同学，应该了解五层协议，那么手机流量上网时的五层网络模型有何不同呢？

从上图可以看出，手机流量上网的主要区别在数据链路层和物理层。在数据链路层，流量上网没有MAC地址的概念，它采用一种点对点协议（PPP），手机端通过拨号方式建立这种PPP连接，然后发送数据。在物理层，流量上网通过手机内置的基带模块进行无线信号的调制、解调工作，从而实现与移动基站之间的电磁波通信。

流量上网的机制

点对点协议支持身 粉验证功能，手机端发起连接时会携带自己的身 粉证明，一般就是手机卡内置的IMSI，这个IMSI也会保存在运营商的数据库中，因此基站就可以验证连接用户的身 粉，当然这个验证过程不是简单的对比IMSI，会有更多安全机制。为了更清楚的了解流量上网机制，下面再来一张4G流量上网时手机与运营商的交互示意图：

核心组件

手机：这其中对流量上网起到关键作用的就是手机卡和基带模块。手机卡中保存了IMSI，全称International Mobile Subscriber Identification Number，国际移动用户识别码。IMSI是手机卡的身 粉标识。

基站：就是外边常见的铁架子信号塔，是一种能覆盖一定范围的无线电收发信息电台，手机会连接到它，然后它再通过光纤连接到运营商网络，从而实现移动通信。

MME：Mobility Management Entity，移动控制单元。手机建立连接时会先访问到这里，负责：手机与基站的接入控制，手机卡的鉴权、会话管理、安全传输，漫游控制、跨运营商通信等。

HSS：Home Subscriber Server，归属签约用户服务器。保存本地签约的手机卡信息，包括手机卡IMSI与手机号的对应关系，手机号的套餐信息、手机号的归属地信息等。

S-GW：Service Gateway，服务网关。4G环境下，用户侧与运营商核心网之间的业务网关。访问能不能进入，能做什么业务，去哪里做业务，是在这里控制的。跨运营商计费、漫游计费等也在这里完成。

P-GW：PDN Gateway，PDN网关。运营商核心网与互联网之间的网关，手机真正上网就是通过它了。它会给手机分配一个IP地址，控制上网的速度，对流量进行计费等。

PCRF：Policy and Charging Rules Function，策略与计费控制单元，保存每个用户的网络访问策略和计费规则。

上网过程

为了方便理解，这里将上网的过程大致分为两个部分（和上图的1、2对应）：

• 1 接入：建立连接时，手机携带IMSI信息，通过基站访问到MME，MME通过HSS验证IMSI信息，然后MME进行一些初始化工作，返回一些鉴权参数给手机，手机再进行一些计算，然后把计算结果返回给MME，MME验证手机的计算结果，验证通过则允许接入。这个过程保证了接入的安全，MME还为后续的数据传输提供了加密传输支持，保护数据不被窃听和篡改，有兴趣的同学可以去详细了解下。

  如果手机卡销售的时候没有写入手机号，手机卡首次注册登记的时候，运营商会从HSS中取出手机号，然后再写入手机卡中。

  实际应用中，为了防止跟踪和攻击，不是每次通信时都要携带IMSI，MME会生成一个临时的GUTI对应到IMSI，就像Web程序中的SessionId。MME还有一定的机制控制GUIT的重新分配。

• 2 传输：手机网络流量的传输，还是先要通过基站，然后下一步进入S-GW，S-GW会检查用户的授权，就像Web程序中检查前端提交过来的SessionId，再看看用户有没有权限进行其提交的业务，这里就是看看用户有没有开通流量上网，这是S-GW通过连接MME实现的。S-GW处理完毕后，数据包会进入P-GW，P-GW在手机使用流量上网时会给用户分配一个IP地址，然后数据包通过网关进入互联网，访问到相关的资源。P-GW还会对上网行为进行速率控制、流量计费等操作，这些策略来源于PCRF，PCRF中的规则是根据HSS中的用户套餐、用户等级等计算出来的。

  对P-GW来说S-GW屏蔽了用户的移动性，手机在多个基站切换时，S-GW不变。

以上就是手机流量上网的基本原理了，可以看到，运营商通过IMSI或者GUTI完全有能力获取到当前上网用户的手机号码。对于运营商的一键登录具体是怎么实现的，我并没有找到相关的介绍，但是可以设想下：手机应用通过运营商的SDK发起获取手机号码的业务请求，此时会携带IMSI或者GUTI，业务请求到达S-GW，S-GW鉴权通过，然后将这个业务请求路由到运营商核心网中获取手机号码的服务，服务根据业务规则从HSS中取出手机号码并进行若干处理。

一键登录的原理

理解了手机流量上网的原理，再来看下一键登录业务是如何实现的，这个部分属于上层应用程序开发，大家应该相对熟悉一些。

如果你接入过微信的第三方应用登录，或者其他类似的第三方应用登录，过程是差不多的。还是先来看图：

这里对一些关键步骤进行说明：

• 2预取手机号掩码：这个手机号掩码需要在请求用户授权的页面展示给用户看，因为获取这个信息要通过电信运营商的网络，所以可能会比较慢，为了提升用户体验，可以在应用启动的时候就去获取，然后缓存一段时间。

• 8授权请求：因为应用获取用户手机号这个事比较敏感，必须让用户清楚的了解并授权之后才能进行，为了确保这件事，运营商的认证SDK提供了这个授权请求页面，用户确认授权后，SDK直接向运营商认证服务发起请求认证，认证服务会返回一个认证Token给应用。应用再通过自己的服务端拿着这个Token找运营商获取手机号码。

• 17生成应用授权Token：应用要维护自己用户的登录状态，这里可以采用传统的Session机制，也可以使用JWT机制。

• 3预取手机号掩码 和 11请求认证，都需要通过手机蜂窝网络通信，也就说需要通过手机流量上网。如果手机同时开启了流量和WIFI，认证SDK会将手机短暂切换到流量上网模式。如果手机没有开启流量，有些SDK还会在上次成功取号之后多缓存一个临时Token，这样也能成功实现一次一键登录，不过这个限制性很大。

这里其实还有一个安全问题：

14登录请求：用户如果随便造一个认证Token，然后就向应用服务提交请求，应用服务再向认证服务提交请求，这属于一种跨站攻击。虽然这个Token可以被阻止，但是不免浪费资源，给服务端带来压力。

这一点微信第三方应用登录做的比较好，用户登录前，应用服务端先生成一个随机数，然后应用前端向应用服务端提交时，带着这个随机数，应用服务端可以验证这个随机数。

号码验证场景

除了用于登录，运营商网关的这种取号能力，还可以用在验证手机号上，在某些关键业务上，比如支付过程中，要求用户输入本机手机号码或者其中的某几位，然后通过运营商认证服务验证手机号是否本机号码。

隐私保护问题

设备唯一标识问题

现在大家对隐私问题关注的越来越多了，经常会出现这种情况：你在某电商网站搜索了某个商品，然后访问其它网站时，都向你推荐这类商品的广告。还有一种感觉很恐怖的情况，你刚和某个人谈论了某件事，然后就在某个App上看到了关于这件事的推荐，有人猜测是App在偷听，不过基于目前的舆论和监督，偷听风险太大，这其中的原因可能真的只是算法太厉害了。

最近几年Android和iOS系统都对App获取手机唯一标识进行了限制，比如IMEI、Mac地址、序列号、广告Id等，目的就是防止用户的信息在多个App之间进行关联，导致泄漏用户的隐私，产生一些安全问题和法律风险，前述跨App的广告行为也自然受到了抑制。

在了解一键登录的技术原理时，看到某运营商提供了一种和SIM卡绑定的设备唯一Id服务，宣传语就是为了应对移动操作系统限制访问手机唯一标识的问题，在现今越来越重视隐私保护的前提下，如果这种能力开放给了广告平台，就是开历史的倒车了。

手机号作为身 份标识的问题

对于国内普遍使用手机号登录的方式，从技术上很难限制App之间进行手机号关联，然后综合分析用户的行为。比如某家大厂运营了多款不同种类的热门App，它就有能力更全面的了解某个用户，如果要限制可能就得通过法律层面来解决了。至于不同厂商之间的手机号关联行为，基于商业利益的保护，不太可能会出现。

在国内这种商业环境下，如果你真的对自己的隐私很关注，最好只使用账号密码的方式登录，否则经常更换手机号可能是一种没办法的办法。

手机号重新销售问题

手机号的总量是有限的，为了有效利用手机号资源，手机号注销以后，经过一段时间就会被运营商重新销售。如果新的手机号拥有者拿着这个手机号登录某个APP，而这个手机号之前已经在这个App上注册过，产生了大量的使用记录，那么此手机号前拥有者的隐私就会被泄漏。所以大家现在都不太敢随便更换手机号，因为注册过的地方太多了，留下了数不清的使用痕迹。

在了解一键登录的技术原理时，还看到某运营商提供了一种“手机号更换绑定SIM卡通知”的服务，应用可以据此解绑重新销售的手机号与应用账号之间的关系，从而保护用户的隐私。在上文中已经提过手机卡使用IMSI进行标识，如果手机号被重新销售，就会绑定新的IMSI，运营商可以据此产生通知。当然运营商还需要排除手机卡更换和携号转网的情况，这些情况下手机号也会绑定新的IMSI。

不得不说运营商的这个服务还是挺赞的👍。

作者：萤火架构
来源：https://juejin.cn/post/7059182505101885471

1、操作系统

Microsoft Windows ：汇编 -> C -> C++

备注：曾经在智能手机的操作系统（Windows Mobile）考虑掺点C#写的程序，比如软键盘，结果因为写出来的程序太慢，实在无法和别的模块合并，最终又回到C++重写。

相信很多朋友都知道Windows Vista，这个系统开发早期比尔盖茨想全部用C#写，但最终因为执行慢而放弃，结果之前无数软件工程师日夜劳作成果一夜之间被宣告作废。

Linux ：C

Apple MacOS ： 主要为C，部分为C++。

备注：之前用的语言比较杂，最早是汇编和Pascal。

Sun Solaris ： C

HP-UX ： C

Symbian OS ： 汇编，主要为C++（诺基亚手机）

Google Android ：2008 年推出：C语言（有传言说是用Java开发的操作系统，但最近刚推出原生的C语言SDK）

RIM BlackBerry OS 4.x ：黑莓 C++

2、图形界面层

Microsoft Windows UI ：C++

Apple MacOS UI (Aqua) ： C++

Gnome （Linux图形界面之一，大脚）： C和C++， 但主要是C

KDE （Linux图形界面）： C++

3、桌面搜索工具

Google Desktop Search ： C++

Microsoft Windows Desktop Search ： C++

Beagle （Linux/Windows/UNIX 下）： C# （基于开源的 .net : Mono）

4、办公软件

Microsoft Office ：在 汇编 -> C -> 稳定在C++

Sun Open Office ： 部分JAVA（对外接口），主要为C++ （开源，可下载其源代码）

Corel Office/WordPerfect Office ： 1996年尝试过Java，次年被抛弃，重新回到C/C++

Adobe Systems Acrobat Reader/Distiller ： C++

5、关系型数据库

Oracle ： 汇编、C、C++、Java。主要为C++

MySQL ： C++

IBM DB2 ：汇编、C、C++，但主要为C

Microsoft SQL Server ： 汇编 -> C->C++

IBM Informix : 汇编、C、C++，但主要为C

SAP DB/MaxDB ： C++

6、Web Browsers/浏览器

Microsoft Internet Explorer ： C++

Mozilla Firefox ： C++

Netscape Navigator ：The code of Netscape browser was written in C, and Netscape engineers, all bought to Java (see M. Cusumano book and article) redeveloped the browser using Java. It was too slow and abandoned. Mozilla, the next version, was later developed using C++.

Safari ： （2003年1月发布）C++

Google Chrome ： （2008的发布）C++

Sun HotJava ： Java （死于1999年）

Opera ： C++ （手机上占用率比较大）

Opera Mini ： Opera Mini (2007) has a very funny architecture, and is indeed using both C++ and Java. The browser is split in two parts, an ultra thin (less than 100Kb) “viewer” client part and a server side responsible of rendering. The first uses Java and receives the page under the OBML format, the latter reuses classical Opera (C++) rendering engine plus Opera’s Small Screen Rendering, on the server. This allows Opera to penetrate various J2ME-enabled portable devices, such as phones, while preserving excellent response time. This comes obviously with a few sacrifices, for instance on JavaScript execution.

Mosaic ： 鼻祖（已死） C 语言

7、邮件客户端

Microsoft Outlook ： C++

IBM Lotus Notes ： Java

Foxmail : Delphi

8、软件开发集成环境/IDE

Microsoft Visual Studio ：C++

Eclipse ： Java （其图形界面SWT基于C/C++）

Code::Blocks ：C++

易语言：C++

火山中文：C++

火山移动：C++

9、虚拟机

Microsoft .Net CLR （.NET的虚拟机）： C++

Java Virtual Machine (JVM) : Java 虚拟机：C++

10、ERP软件 （企业应用）

SAP mySAP ERP ： C，后主要为“ABAP/4”语言

Oracle Peoplesoft ： C++ -> Java

Oracle E-Business Suite ： Java

11、商业智能（Business Intelligence ）

Business Objects ： C++

12、图形处理

Adobe Photoshop ： C++

The GIMP ： C

13、搜索引擎

Google ： 汇编 与 C++，但主要为C++

14、著名网站

eBay ： 2002年为C++，后主要迁至Java

facebook ： C++ 和 PHP

This line is only about facebook, not its plugins. Plugins can be developed in many different technologies, thanks to facebook’s ORB/application server, Thrift. Thrift contains a compiler coded in C++. facebook people write about Thrift: “The multi-language code generation is well suited for search because it allows for application development in an efficient server side language (C++) and allows the Facebook PHP-based web application to make calls to the search service using Thrift PHP libraries.” Aside the use of C++, facebook has adopted a LAMP architecture.

阿里巴巴和淘宝：php->C++/Java(主要用)

15、游戏

汇编、C、C++

星际争霸、魔兽争霸、CS、帝国时代、跑跑卡丁车、传奇、魔兽世界… 数不胜数了，自己数吧

都是用C开发的，C语言靠近系统地称，执行速度最快。比如你的两个朋友与你分别玩用VB、Java、与C编写的“跑跑卡丁车”，你玩C编写的游戏已经跑玩结束了，发现你的两个朋友还没开始跑呢，那是相当的卡啊。

16、编译器

Microsoft Visual C++ 编译器： C++

Microsoft Visual Basic 解释、编译器：C++

Microsoft Visual C# ：编译器： C++

gcc (GNU C compiler) ： C

javac (Sun Java compiler) ： Java

Perl ： C++

PHP ： C

17、3D引擎

Microsoft DirectX ： C++

OpenGL ： C

OGRE 3D ： C++

18、Web Servers （网页服务）

Apache ： C和C++，但主要为C

Microsoft IIS ： C++

Tomcat ： Java

Jboss ： Java

19、邮件服务

Microsoft Exchange Server ： C->C++

Postfix : C

hMailServer : C++

Apache James : Java

20、CD/DVD刻录

Nero Burning ROM ： C++

K3B ： C++

21、媒体播放器

Nullsoft Winamp ： C++

Microsoft Windows Media Player ： C++

22、Peer to Peer （P2P软件）

eMule ： C++

μtorrent ： C++

Azureus ： Java （图形界面使用基于C/C++的SWT，类Eclipse）

23、全球定位系统（GPS）

TomTom ： C++

Hertz NeverLost ： C++

Garmin ： C++

Motorola VIAMOTO ： 2007年6月，停止服务，Java

24、3D引擎

Microsoft DirectX ： C++（相信玩游戏的同学都知道这个，现在最高版本是DX11）

OpenGL ： C

OGRE 3D ： C++

25、服务器软件

Apache：C

Nginx：C

IIS：C

26、其它

OpenStack：Python

作者：土豆居士
来源：一口Linux

WinMerge

WinMerge是一款运行于Windows系统下的文件比较和合并工具，使用它可以非常方便地比较多个文档内容，适合程序员或者经常需要撰写文稿的朋友使用。

WinMerge会将两个文件内容做对比，并在相异之处以高亮度的方式显示，让使用者可以很快的查知；可以直接让左方的文件内容直接覆盖至右方，或者反过来也可以覆盖。

Diffuse

Diffuse在命令行中的速度是相当快的，支持像 C++、Python、Java、XML 等语言的语法高亮显示。可视化比较，非常直观，支持两相比较和三相比较。这就是说，使用 Diffuse 你可以同时比较两个或三个文本文件。

支持常见的版本控制工具，包括 CVS、subversion、git、mercurial 等，你可以通过 Diffuse 直接从版本控制系统获取源代码，以便对其进行比较和合并。

Beyond Compare

Beyond Compare可以很方便地对比出两份源代码文件之间的不同之处，相差的每一个字节用颜色加以表示，查看方便，支持多种规则对比。

Beyond Compare选择最好的方法来突出不同之处，文本文件可以用语法高亮和设置比较规则的方法进行查看和编辑，适用于用于文档、源代码和HTML。

Altova DiffDog

是一款用于文件、目录、数据库模式与表格对比与合并的使用工具。

这个强大易用的对比/合并工具可以让你通过其直观的可视化界面快速比较和合并文本或源代码文件，同步目录以及比较数据库模式与表格。DiffDog还提供了先进XML的差分和编辑功能。

AptDiff

AptDiff是一个文件比较工具，可以对文本和二进制文件进行比较和合并，适用于软件开发、网络设计和其它的专业领域。

它使用方便，支持键盘快捷键，可以同步进行横向和纵向卷动，支持Unicode格式和大于4GB的文件，可以生成HTML格式的比较报告。

Code Compare

Code Compare是一款用于程序代码文件的比较工具，目前Code Compare支持的对比语言有：C#、C++、CSS、HTML、Java、JavaScrip等代码语言。

Code Compare的运行环境为Visual Studio，而Visual Studio可以方便所有的程序开发设计。

作者：小白学视觉
来源：https://mp.weixin.qq.com/s/I5__jnuDAIJlWbCHJsPDRQ

IEEE Spectrum 2021 年度编程语言排行榜新鲜出炉，不出意料，Java 仍稳居前三。自 1995 年诞生以来，Java 始终是互联网行业炙手可热的编程语言。近年来，新的编程语言层出不穷，Java 如何做到 26 年来盛行不衰？面对技术新趋势，Java 语言将如何发展？在亚马逊云科技 re:Invent 十周年之际，InfoQ 有幸对 Java 父 James Gosling 博士进行了一次独家专访。James Gosling 于 2017 年作为“杰出工程师”加入亚马逊云科技，负责为产品规划和产品发布之类的工作提供咨询支持，并开发了不少原型设计方案。在本次采访中，James Gosling 谈到了 Java 的诞生与发展、他对众多编程语言的看法、编程语言的未来发展趋势以及云计算带来的改变等问题。

Java 的诞生与发展

InfoQ：Java 语言是如何诞生的？是什么激发您创建一门全新的语言？

James Gosling：Java 的诞生其实源于物联网的兴起。当时，我在 Sun 公司工作，同事们都觉得嵌入式设备很有发展前景，而且随着设备数量的激增，整个世界正逐渐向智能化的方向发展。我们投入大量时间与不同行业的从业者进行交流，也拜访了众多东南亚、欧洲的从业者，结合交流心得和行业面临的问题，决定构建一套设计原型。正是在这套原型的构建过程中，我们深刻地意识到当时主流的语言 C++ 存在问题。

最初，我们只打算对 C++ 做出一点小调整，但随着工作的推进、一切很快“失控”了。我们构建出不少非常有趣的设备原型，也从中得到了重要启示。因此，我们及时对方向进行调整，希望设计出某种适用于主流业务和企业计算的解决方案，这正是一切故事的开端。

InfoQ：Java 作为一门盛行不衰的语言，直到现在依旧稳居编程语言的前列，其生命力何在？

James Gosling：Java 得以拥有顽强的生命力背后有诸多原因。

首先，采用 Java 能够非常便捷地进行多线程编程，能大大提升开发者的工作效率。

其次，Java 提供多种内置安全功能，能够帮助开发者及时发现错误、更加易于调试，此外，各种审查机制能够帮助开发者有效识别问题。

第三，热修复补丁功能也非常重要，亚马逊开发者开发出的热补丁修复程序，能够在无须停机的前提下修复正在运行的程序，这是 Java 中非常独特的功能。

第四，Java 拥有很好的内存管理机制，自动垃圾收集大大降低了内存泄露或者双重使用问题的几率。总之，Java 的设计特性确实提升了应用程序的健壮性，特别是极为强大的现代垃圾收集器方案。如果大家用过最新的长期支持版本 JDK17，应该对其出色的垃圾收集器印象深刻。新版本提供多种强大的垃圾收集器，适配多种不同负载使用。另外，现代垃圾收集器停顿时间很短、运行时的资源消耗也非常低。如今，很多用户会使用体量极为庞大的数据结构，而只要内存能容得下这种 TB 级别的数据，Java 就能以极快的速度完成庞大数据结构的构建。

InfoQ：Java 的版本一直以来更新得比较快，几个月前发布了最新的 Java17 版本，但 Java8 仍然是开发人员使用的主要版本，新版本并未“得宠”，您认为主要的原因是什么？

James Gosling：对继续坚守 Java8 的朋友，我想说“是时候作出改变了”。新系统全方位性更强、速度更快、错误也更少、扩展效率更高。无论从哪个角度看，大家都有理由接纳 JDK17。确实，大家在从 JDK8 升级到 JDK9 时会遇到一个小问题，这也是 Java 发展史中几乎唯一一次真正重大的版本更替。大多数情况下，Java 新旧版本更替都非常简单。只需要直接安装新版本，一切就能照常运作。长久以来，稳定、非破坏性的升级一直是 Java 的招牌特性之一，我们也不希望破坏这种良好的印象。

InfoQ：回顾当初，你觉得 Java 设计最成功的点是什么？相对不太满意的地方是什么？

James Gosling：这其实是一种博弈。真正重要的是 Java 能不能以更便利的方式完成任务。我们没办法设想，如果放弃某些问题域，Java 会不会变得更好？或者说，如果我现在重做 Java，在取舍上会有不同吗？区别肯定会有，但我估计我的取舍可能跟大多数人都不一样，毕竟我的编程风格也跟多数人不一样。不过总的来讲，Java 确实还有改进空间。

InfoQ：有没有考虑简化一下 Java？

James Gosling：我可太想简化一下 Java 了。毕竟简化的意义就是放下包袱、轻装上阵。所以 JavaScript 刚出现时，宣传的就是精简版 Java。但后来人们觉得 JavaScript 速度太慢了。在 JavaScript 的早期版本中，大家只是用来执行外部验证之类的简单事务，所以速度还不太重要。但在人们打算用 JavaScript 开发高性能应用时，得出的解决方案就成了 TypeScript。其实我一直觉得 TypeScript 的定位有点搞笑——JavaScript 就是去掉了 Type 的 Java，而 TypeScript 在 JavaScript 的基础上又把 type 加了回来。Type 系统有很多优势，特别是能让系统运行得更快，但也确实拉高了软件开发者的学习门槛。但如果你想成为一名专业的软件开发者，那最好能克服对于学习的恐惧心理。

Java 之父的编程语言之见

InfoQ：一款优秀的现代化编程语言应该是怎样的？当下最欣赏哪一种编程语言的设计理念？

James Gosling：我个人还是会用最简单的评判标准即这种语言能不能改善开发者的日常工作和生活。我尝试过很多语言，哪种更好主要取决于我想干什么。如果我正要编写低级设备驱动程序，那我可能倾向于选择 Rust。但如果需要编写的是用来为自动驾驶汽车建立复杂数据结构的大型导航系统，那我几乎肯定会选择 Java。

InfoQ：数据科学近两年非常热门，众所周知，R 语言和 Python 是数据科学领域最受欢迎的两门编程语言，那么，这两门语言的发展前景怎么样？因具体的应用领域产生专用的编程语言，会是接下来编程语言领域的趋势之一吗？

James Gosling：我是领域特定语言的铁粉，也深切认同这些语言在特定领域中的出色表现。大多数领域特定语言的问题是，它们只能在与世隔绝的某一领域中发挥作用，而无法跨越多个领域。这时候大家更愿意选择 Java 这类语言，它虽然没有针对任何特定领域作出优化，但却能在跨领域时表现良好。所以，如果大家要做的是任何形式的跨领域编程，肯定希望单一语言就能满足所有需求。有时候，大家也会尝试其他一些手段，希望在两种不同的领域特定语言之间架起一道桥梁，但一旦涉及两种以上的语言，我们的头脑通常就很难兼顾了。

InfoQ：Rust 一直致力于解决高并发和高安全性系统问题，这也确实符合当下绝大部分应用场景的需求，对于 Rust 语言的现在和未来您怎么看？

James Gosling：在我看来，Rust 太过关注安全了，这让它出了名的难学。Rust 解决问题的过程就像是证明定理，一步也不能出错。如果我们只需要编写一小段代码，用于某种固定不变的设备，那 Rust 的效果非常好。但如果大家需要构建一套具有高复杂度动态数据结构的大规模系统，那么 Rust 的使用难度就太高了。

编程语言的学习和发展

InfoQ：编程语言倾向于往更加低门槛的方向发展，开发者也更愿意选择学习门槛低的开发语言，一旦一门语言的学习成本过高，开发者可能就不愿意去选择了。对于这样的现象，您怎么看？

James Gosling：要具体问题具体分析。我到底需要 Rust 中的哪些功能特性？我又需要 Java 中的哪些功能特性？很多人更喜欢 Python，因为它的学习门槛真的很低。但跑跑基准测试，我们就会发现跟 Rust 和 Java 相比，Python 的性能实在太差了。如果关注性能，那 Rust 或 Java 才是正确答案。另外，如果你需要的是只有 Rust 能够提供的那种致密、安全、严谨的特性，代码的编写体量不大，而且一旦出问题会造成严重后果，那 Rust 就是比较合适的选择。只能说某些场景下某些语言更合适。Java 就属于比较折衷的语言，虽然不像 Python 那么好学，但也肯定不算难学。

InfoQ：当前，软件项目越来越倾向采用多语言开发，对程序员的要求也越来越高。一名开发人员，应该至少掌握几种语言？最应该熟悉和理解哪些编程语言？

James Gosling：我刚刚入行时，市面上已经有很多语言了。我学了不少语言，大概有几十种吧。但很多语言的诞生本身就很荒谬、很没必要。很多语言就是同一种语言的不同方言，因为它们只是在用不同的方式实现基本相同的语言定义。最让我振奋的是我生活在一个能够致力于解决问题的世界当中。Java 最大的吸引力也正在于此，它能帮助我们解决几乎任何问题。具有普适性的语言地位高些、只适用于特定场景的语言则地位低些，对吧？所以到底该学什么语言，取决于你想解决什么问题、完成哪些任务。明确想要解决什么样的问题才是关键。

InfoQ：2021 年，技术圈最热门的概念非元宇宙莫属，您认为随着元宇宙时代的到来，新的应用场景是否会对编程语言有新的需求？可否谈谈您对未来编程语言的理解？

James Gosling：其实人们从很早开始就在构建这类虚拟世界系统了，所以我觉得元宇宙概念对编程不会有什么影响。唯一的区别是未来我们可以漫步在这些 3D 环境当中，类似于大型多人游戏那种形式。其实《我的世界》就是用户构建型元宇宙的雏形嘛，所以这里并没有什么真正新鲜的东西，仍然是游戏粉加上社交互动机制的组合。我还想强调一点，虚拟现实其实没什么意思。我更重视与真实人类的面对面互动，真的很难想象自己有一天会跟独角兽之类的虚拟形象聊天。

写在最后：云计算带来的改变

InfoQ：您最初是从什么时候或者什么具体事件开始感受到云计算时代的到来的？

James Gosling：云计算概念的出现要远早出云计算的真正实现。因为人们一直把计算机摆在大机房里，再通过网络连接来访问，这其实就是传统的 IT 服务器机房，但这类方案维护成本高、建造成本高、扩展成本也高，而且对于人员技能等等都有着很高的要求。如果非要说，我觉得多租户云的出现正是云计算迎来飞跃的关键，这时候所有的人力与资本支出都由云服务商负责处理，企业客户再也不用为此烦心了。他们可以单纯关注自己的业务重心，告别那些没完没了又没有任何差异性可言的繁重工作。

InfoQ：云计算如今已经形成巨大的行业和生态，背后的根本驱动力是什么？

James Gosling：云计算的驱动力实际上与客户当前任务的实际规模有很大关系。过去几年以来，数字化转型已经全面掀起浪潮，而这波转型浪潮也凸显出新的事实，即我们还有更多的探索空间和机遇，例如，现在人们才刚刚开始探索真正的机器学习能做些什么，能够以越来越有趣且多样的方法处理大规模数据，开展数据分析，获取洞见并据此做出决策，而这一切既是客户需求，也为我们指明了接下来的前进方向。亚马逊云科技做为云科技领导者，引领着云科技的发展，改变着 IT 世界，切实解决了企业客户的诸多痛点。

作者：张雅文
来源：https://mp.weixin.qq.com/s/B4_YaVrnltm54aV4cW1XpA

文章目录

• 什么是YAML

• 基本语法

• 数据类型

  • 标量

  • 对象

  • 数组

• 文本块

• 显示指定类型

• 引用

• 单文件多配置

什么是YAML

YAML是"YAML Ain’t a Markup Language"（YAML不是一种标记语言）的递归缩写。YAML的意思其实是：“Yet Another Markup Language”（仍是一种标记语言）。主要强度这种语音是以数据为中心，而不是以标记语音为重心，例如像xml语言就会使用大量的标记。

YAML是一个可读性高，易于理解，用来表达数据序列化的格式。它的语法和其他高级语言类似，并且可以简单表达清单（数组）、散列表，标量等数据形态。它使用空白符号缩进和大量依赖外观的特色，特别适合用来表达或编辑数据结构、各种配置文件等。

YAML的配置文件后缀为 .yml，例如Springboot项目中使用到的配置文件 application.yml 。

基本语法

• YAML使用可打印的Unicode字符，可使用UTF-8或UTF-16。

• 数据结构采用键值对的形式，即 键名称: 值，注意冒号后面要有空格。

• 每个清单（数组）成员以单行表示，并用短杠+空白（- ）起始。或使用方括号（[]），并用逗号+空白（, ）分开成员。

• 每个散列表的成员用冒号+空白（: ）分开键值和内容。或使用大括号（{ }），并用逗号+空白（, ）分开。

• 字符串值一般不使用引号，必要时可使用，使用双引号表示字符串时，会转义字符串中的特殊字符（例如\n）。使用单引号时不会转义字符串中的特殊字符。

• 大小写敏感

• 使用缩进表示层级关系，缩进不允许使用tab，只允许空格，因为有可能在不同系统下tab长度不一样

• 缩进的空格数可以任意，只要相同层级的元素左对齐即可

• 在单一文件中，可用连续三个连字号（—）区分多个文件。还有选择性的连续三个点号（…）用来表示文件结尾。

• '#'表示注释，可以出现在一行中的任何位置，单行注释

• 在使用逗号及冒号时，后面都必须接一个空白字符，所以可以在字符串或数值中自由加入分隔符号（例如：5,280或http://www.wikipedia.org）而不需要使用引号。

数据类型

• 纯量（scalars）：单个的、不可再分的值

• 对象：键值对的集合，又称为映射（mapping）/ 哈希（hashes） / 字典（dictionary）

• 数组：一组按次序排列的值，又称为序列（sequence） / 列表（list）

标量

标量是最基础的数据类型，不可再分的值，他们一般用于表示单个的变量，有以下七种：

1. 字符串

2. 布尔值

3. 整数

4. 浮点数

5. Null

6. 时间

7. 日期

# 字符串
string.value: Hello!我是陈皮!
# 布尔值，true或false
boolean.value: true
boolean.value1: false
# 整数
int.value: 10
int.value1: 0b1010_0111_0100_1010_1110 # 二进制
# 浮点数
float.value: 3.14159
float.value1: 314159e-5 # 科学计数法
# Null，~代表null
null.value: ~
# 时间，时间使用ISO 8601格式，时间和日期之间使用T连接，最后使用+代表时区
datetime.value: !!timestamp 2021-04-13T10:31:00+08:00
# 日期,日期必须使用ISO 8601格式，即yyyy-MM-dd
date.value: !!timestamp 2021-04-13

这样，我们就可以在程序中引入了，如下：

@RestController
@RequestMapping("demo")
public class PropConfig {
    
    @Value("${string.value}")
    private String stringValue;

    @Value("${boolean.value}")
    private boolean booleanValue;

    @Value("${boolean.value1}")
    private boolean booleanValue1;

    @Value("${int.value}")
    private int intValue;

    @Value("${int.value1}")
    private int intValue1;

    @Value("${float.value}")
    private float floatValue;

    @Value("${float.value1}")
    private float floatValue1;

    @Value("${null.value}")
    private String nullValue;

    @Value("${datetime.value}")
    private Date datetimeValue;

    @Value("${date.value}")
    private Date datevalue;
}

对象

我们知道单个变量可以用键值对，使用冒号结构表示 key: value，注意冒号后面要加一个空格。可以使用缩进层级的键值对表示一个对象，如下所示：

person:
  name: 陈皮
  age: 18
  man: true

然后在程序对这几个属性进行赋值到Person对象中，注意Person类要加get/set方法，不然属性会无法正确取到配置文件的值。使用@ConfigurationProperties注入对象，@value不能很好的解析复杂对象。

package com.nobody;

import lombok.Getter;
import lombok.Setter;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Configuration;

/**
 * @Description
 * @Author Mr.nobody
 * @Date 2021/4/13
 * @Version 1.0.0
 */
@Configuration
@ConfigurationProperties(prefix = "my.person")
@Getter
@Setter
public class Person {
    private String name;
    private int age;
    private boolean man;
}

当然也可以使用 key:{key1: value1, key2: value2, ...}的形式，如下：

person: {name: 陈皮, age: 18, man: true}

数组

可以用短横杆加空格 -开头的行组成数组的每一个元素，如下的address字段：

person:
  name: 陈皮
  age: 18
  man: true
  address:
    - 深圳
    - 北京
    - 广州

也可以使用中括号进行行内显示形式，如下：

person:
  name: 陈皮
  age: 18
  man: true
  address: [深圳, 北京, 广州]

在代码中引入方式如下：

package com.nobody;

import lombok.Getter;
import lombok.Setter;
import lombok.ToString;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Configuration;

import java.util.List;

/**
 * @Description
 * @Author Mr.nobody
 * @Date 2021/4/13
 * @Version 1.0.0
 */
@Configuration
@ConfigurationProperties(prefix = "person")
@Getter
@Setter
@ToString
public class Person {
   
     
     
    private String name;
    private int age;
    private boolean man;
    private List<String> address;
}

如果数组字段的成员也是一个数组，可以使用嵌套的形式，如下：

person:

  name: 陈皮

  age: 18

  man: true

  address: [深圳, 北京, 广州]

  twoArr:

    -

      - 2

      - 3

      - 1

    -

      - 10

      - 12

      - 30

package com.nobody;



import lombok.Getter;

import lombok.Setter;

import lombok.ToString;

import org.springframework.boot.context.properties.ConfigurationProperties;

import org.springframework.context.annotation.Configuration;



import java.util.List;



@Configuration

@ConfigurationProperties(prefix = "person")

@Getter

@Setter

@ToString

public class Person {

   

     

     

    private String name;

    private int age;

    private boolean man;

    private List<String> address;

    private List<List<Integer>> twoArr;

}

如果数组成员是一个对象，则用如下两种形式形式：

childs:

  -

    name: 小红

    age: 10

  -

    name: 小王

    age: 15

childs: [{name: 小红, age: 10}, {name: 小王, age: 15}]

文本块

如果你想引入多行的文本块，可以使用|符号，注意在冒号:和 |符号之间要有空格。

person:

  name: |

    Hello Java!!

    I am fine!

    Thanks! GoodBye!

它和加双引号的效果一样，双引号能转义特殊字符：

person:

  name: "Hello Java!!\nI am fine!\nThanks! GoodBye!"

显示指定类型

有时我们需要显示指定某些值的类型，可以使用 !（感叹号）显式指定类型。!单叹号通常是自定义类型，!!双叹号是内置类型，例如：

# 指定为字符串

string.value: !!str HelloWorld!

# !!timestamp指定为日期时间类型

datetime.value: !!timestamp 2021-04-13T02:31:00+08:00

内置的类型如下：

• !!int：整数类型

• !!float：浮点类型

• !!bool：布尔类型

• !!str：字符串类型

• !!binary：二进制类型

• !!timestamp：日期时间类型

• !!null：空值

• !!set：集合类型

• !!omap，!!pairs：键值列表或对象列表

• !!seq：序列

• !!map：散列表类型

引用

引用会用到 &锚点符合和 *星号符号，&用来建立锚点，<< 表示合并到当前数据，* 用来引用锚点。

xiaohong: &xiaohong

  name: 小红

  age: 20



dept:

  id: D15D8E4F6D68A4E88E

  <<: *xiaohong

上面最终相当于如下：

xiaohong:

  name: 小红

  age: 20



dept:

  id: D15D8E4F6D68A4E88E

  name: 小红

  age: 20

还有一种文件内引用，引用已经定义好的变量，如下：

base.host: https://chenpi.com

add.person.url: ${base.host}/person/add

单文件多配置

可以在同一个文件中，实现多文档分区，即多配置。在一个yml文件中，通过 — 分隔多个不同配置，根据spring.profiles.active 的值来决定启用哪个配置

#公共配置

spring:

  profiles:

    active: pro # 指定使用哪个文档块

---

#开发环境配置

spring:

  profiles: dev # profiles属性代表配置的名称



server:

  port: 8080

---

#生产环境配置

spring:

  profiles: pro



server:

  port: 8081

作者：陈皮的JavaLib
来源：https://blog.csdn.net/chenlixiao007/article/details/115654824

本来想着快过年了偷个懒休息下，没想到被兄弟们连续催更，没办法，博主暖男嘛，掐着人中也要更，兄弟们卷起来

volatile关键字可以说是Java虚拟机提供的最轻量级的同步机制，但对于为什么它只能保证可见性，不保证原子性，它又是如何禁用指令重排的，还有很多同学没彻底理解

相信我，坚持看完这篇文章，你将牢牢掌握一个Java核心知识点

先说它的两个作用：

• 保证变量在内存中对线程的可见性

• 禁用指令重排

每个字都认识，凑在一起就麻了

这两个作用通常很不容易被我们Java开发人员正确、完整地理解，以至于许多同学不能正确地使用volatile

关于可见性

不多bb，码来

public class VolatileTest {
    private static volatile int count = 0;
    
    private static void increase() {
    count++;
    }

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                for (int j = 0; j < 10000; j++) {
                    increase();
                }
            }).start();
        }
        // 所有线程累加完成后输出
        while (Thread.activeCount() > 2) Thread.yield();
        System.out.println(count);
    }
}

代码很好理解，开了十个线程对同一个共享变量count做累加，每个线程累加1w次

count我们已经用volatile修饰，已经保证了count对十个线程在内存中的可见性，按理说十个线程执行完毕count的值应该10w

然鹅，运行多次，结果都远小于期望值

是哪个环节出了问题？

你肯定听过一句话：volatile只保证可见性，不保证原子性

这句话就是答案，但是依旧很多人没搞懂其中的奥秘

说来话长我长话短说，简单来讲就是 count++这个操作不是原子的，它是分三步进行

1. 从内存读取 count 的值

2. 执行 count + 1

3. 将 count 的新值写回

要彻底搞懂这个问题，我们得从字节码入手

下面是increase方法编译后的字节码

看不懂没关系，我们一行一行来看：

1. GETSTATIC：读取 count 的当前值

2. ICONST_1：将常量 1 加载到栈顶

3. IADD：执行+1

4. PUTSTATIC：写入count最新值

ICONST_1和IADD其实就是真正的++操作

关键点来了，volatile只能保证线程在GETSTATIC这一步拿到的值是最新的，但当该线程执行到下面几行指令时，这期间可能就有其它线程把count的值修改了，最终导致旧值把真正的新值覆盖

懂我意思吗

所以，并发编程中，只靠volatile修饰共享变量是不可靠的，最终还是要通过对关键方法加锁来保证线程安全

就如上面的demo，稍加修改就能实现真正的线程安全

最简单的，给increase方法加个synchronized （synchronized怎么实现线程安全的我就不啰嗦了，我以前讲过 synchronized底层实现原理）

private synchronized static void increase() {
    ++count;
}

run几下

这不就妥了嘛

到现在，对于以下两点你应该有了新的认知

1. volatile保证变量在内存中对线程的可见性

2. volatile只保证可见性，不保证原子性

关于指令重排

并发编程中，cpu自身和虚拟机为了提高执行效率，都会采用指令重排（在保证不影响结果的前提下，将某些代码乱序执行）

1. 关于cpu：为了从分利用cpu，实际执行指令时会做优化；

2. 关于虚拟机：在HotSpot vm中，为了提升执行效率，JIT(即时编译)模式也会做指令优化

指令重排在大部分场景下确实能提升执行效率，但有些场景对代码执行顺序是强依赖的，此时我们需要禁用指令重排，如下面这个场景

伪代码取自《深入理解Java虚拟机》：

其描述的场景是开发中常见配置读取过程，只是我们在处理配置文件时一般不会出现并发，所以没有察觉这会有问题。
试想一下，如果定义initialized变量时没有使用volatile修饰，就可能会由于指令重排序的优化，导致位于线程A中最后一条代码“initialized=true”被提前执行（这里虽然使用Java作为伪代码，但所指的重排序优化是机器级的优化操作，提前执行是指这条语句对应的汇编代码被提前执行），这样在线程B中使用配置信息的代码就可能出现错误，而volatile通过禁止指令重排则可以避免此类情况发生

禁用指令重排只需要将变量声明为volatile，是不是很神奇

我们来看看volatile是如何实现禁用指令重排的

也借用《深入理解Java虚拟机》的一个例子吧，比较好理解

这是个单例模式的实现，下面是它的部分字节码，红框中 mov%eax，0x150(%esi) 是对instance赋值

可以看到，在赋值后，还执行了 lock addl$0x0，(%esp) 指令，关键点就在这儿，这行指令相当于此处设置了个 内存屏障 ，有了内存屏障后，cpu或虚拟机在指令重排时就不能把内存屏障后面的指令提前到内存屏障前面，好好捋一下这段话

最后，留一个能加深大家对volatile理解的问题，兄弟们好好思考下：

Java代码明明是从上往下依次执行，为什么会出现指令重排这个问题？

ok我话说完
————————————————
作者：负债程序猿
来源：https://blog.csdn.net/qq_33709582/article/details/122415754

说起动态规划，我不知道你有没有这样的困扰，在掌握了一些基础算法和数据结构之后，碰到一些较为复杂的问题还是无从下手，面试时自然也是胆战心惊。如果我说动态规划是个玄幻的问题其实也不为过。究其原因，我觉得可以归因于这样两点：

• 你对动态规划相关问题的套路和思想还没有完全掌握；

• 你没有系统地总结过究竟有哪些问题可以用动态规划解决。

知己知彼，你想把动态规划作为你的面试武器之一，就得足够了解它；而应对面试，总结、归类问题其实是个不错的选择，这在我们刷题的时候其实也能感觉得到。那么，我们就针对以上两点，系统地谈一谈究竟什么样的问题可以用动态规划来解。

一、动态规划是一种思想

动态规划算法，这种叫法我想你应该经常听说。嗯，从道理上讲这么叫我觉得也没错，首先动态规划它不是数据结构，这一点毋庸置疑，并且严格意义上来说它就是一种算法。但更加准确或者更加贴切的提法应该是说动态规划是一种思想。那算法和思想又有什么区别呢？

一般来说，我们都会把算法和数据结构放一起来讲，这是因为它们之间密切相关，而算法也往往是在特定数据结构的基础之上对解题方案的一种严谨的总结。

比如说，在一个乱序数组的基础上进行排序，这里的数据结构指的是什么呢？很显然是数组，而算法则是所谓的排序。至于排序算法，你可以考虑使用简单的冒泡排序或效率更高的快速排序方法等等来解决问题。

没错，你应该也感觉到了，算法是一种简单的经验总结和套路。那什么是思想呢？相较于算法，思想更多的是指导你我来解决问题。

比如说，在解决一个复杂问题的时候，我们可以先将问题简化，先解决简单的问题，再解决难的问题，那么这就是一种指导解决问题的思想。另外，我们常说的分治也是一种简单的思想，当然它在诸如归并排序或递归算法当中会常常被提及。

而动态规划就是这样一个指导我们解决问题的思想：你需要利用已经计算好的结果来推导你的计算，即大规模问题的结果是由小规模问题的结果运算得来的。

总结一下：算法是一种经验总结，而思想则是用来指导我们解决问题的。既然动态规划是一种思想，那它实际上就是一个比较抽象的概念了，也很难和实际的问题关联起来。所以说，弄清楚什么样的问题可以使用动态规划来解就显得十分重要了。

二、动态规划问题的特点

动态规划作为运筹学上的一种最优化解题方法，在算法问题上已经得到广泛应用。接下来我们就来看一下动归问题所具备的一些特点。

2.1 最优解问题

除非你碰到的问题是简单到找出一个数组中最大的值这样，对这种问题来说，你可以对数组进行排序，然后取数组头或尾部的元素，如果觉得麻烦，你也可以直接遍历得到最值。不然的话，你就得考虑使用动态规划来解决这个问题了。这样的问题一般都会让你求最大子数组、求最长递增子数组、求最长递增子序列或求最长公共子串、子序列等等。

如果碰到求最值问题，我们可以使用下面的套路来解决问题：

• 优先考虑使用贪心算法的可能性；

• 然后是暴力递归进行穷举，针对数据规模不大的情况；

• 如果上面两种都不适合，那么再选择动态规划。

可以看到，求解动态规划的核心问题其实就是穷举。当然了，动态规划问题也不会这么简单了事，我们还需要考虑待解决的问题是否存在重叠子问题、最优子结构等特性。

清楚了动态规划算法的特点，接下来我们就来看一下哪些问题适合用动态规划思想来解题。

1. 乘积最大子数组

给你一个整数数组 numbers，找出数组中乘积最大的连续子数组（该子数组中至少包含一个数字），返回该子数组的乘积。

示例1：
输入: [2,7,-2,4]
输出: 14
解释: 子数组 [2,7] 有最大乘积 14。


示例2：
输入: [-5,0,3,-1]
输出: 3
解释: 结果不能为 15, 因为 [-5,3,-1] 不是子数组，是子序列。

首先，很明显这个题目当中包含一个“最”字，使用动态规划求解的概率就很大。这个问题的目的就是从数组中寻找一个最大的连续区间，确保这个区间的乘积最大。由于每个连续区间可以划分成两个更小的连续区间，而且大的连续区间的结果是两个小连续区间的乘积，因此这个问题还是求解满足条件的最大值，同样可以进行问题分解，而且属于求最值问题。同时，这个问题与求最大连续子序列和比较相似，唯一的区别就是你需要在这个问题里考虑正负号的问题，其它就相同了。

对应实现代码：

class Solution {
public:
    int maxProduct(vector<int>& nums) {
        if(nums.empty()) return 0;

        int curMax = nums[0];
        int curMin = nums[0];
        int maxPro = nums[0];
        for(int i=1; i<nums.size(); i++){
            int temp = curMax;    // 因为curMax在下一行可能会被更新，所以保存下来
            curMax = max(max(curMax*nums[i], nums[i]), curMin*nums[i]);
            curMin = min(min(curMin*nums[i], nums[i]), temp*nums[i]);
            maxPro = max(curMax, maxPro);
        }
        return maxPro;
    }
};

2. 最长回文子串

问题：给定一个字符串 s，找到 s 中最长的回文子串。你可以假设 s 的最大长度为 1000。

示例1：
输入: "babad"
输出: "bab"


示例2：
输入: "cbbd"
输出: "bb"

【回文串】是一个正读和反读都一样的字符串，比如“level”或者“noon”等等就是回文串。这个问题依然包含一个“最”字，同样由于求解的最长回文子串肯定包含一个更短的回文子串，因此我们依然可以使用动态规划来求解这个问题。

对应实现代码：

class Solution {
        public boolean isPalindrome(String s, int b, int e){//判断s[b...e]是否为回文字符串
        int i = b, j = e;
        while(i <= j){
            if(s.charAt(i) != s.charAt(j)) return false;
            ++i;
            --j;
        }
        return true;
    }
    public String longestPalindrome(String s) {
        if(s.length() <=1){
            return s;
        }
        int l = 1, j = 0, ll = 1;
        for(int i = 1; i < s.length(); ++i){
             //下面这个if语句就是用来维持循环不变式，即ll恒表示：以第i个字符为尾的最长回文子串的长度
             if(i - 1 - ll >= 0 && s.charAt(i) == s.charAt(i-1-ll)) ll += 2;
             else{
                 while(true){//重新确定以i为边界，最长的回文字串长度。确认范围为从ll+1到1
                     if(ll == 0||isPalindrome(s,i-ll,i)){
                         ++ll;
                         break;
                     }
                     --ll;
                 }
             }
             if(ll > l){//更新最长回文子串信息
                l = ll;
                j = i;
            }
        }
        return s.substring(j-l+1, j+1);//返回从j-l+1到j长度为l的子串
    }
}

3. 最长上升子序列

问题：给定一个无序的整数数组，找到其中最长上升子序列的长度。可能会有多种最长上升子序列的组合，你只需要输出对应的长度即可。

示例：
输入: [10,9,2,5,3,7,66,18]
输出: 4
解释: 最长的上升子序列是 [2,3,7,66]，它的长度是 4。

这个问题依然是一个最优解问题，假设我们要求一个长度为 5 的字符串中的上升自序列，我们只需要知道长度为 4 的字符串最长上升子序列是多长，就可以根据剩下的数字确定最后的结果。
对应实现代码：

class Solution {
    public int lengthOfLIS(int[] nums) {
        if(nums.length == 0) return 0;
        int[] dp = new int[nums.length];
        int res = 0;
        Arrays.fill(dp, 1);
        for(int i = 0; i < nums.length; i++) {
            for(int j = 0; j < i; j++) {
                if(nums[j] < nums[i]) dp[i] = Math.max(dp[i], dp[j] + 1);
            }
            res = Math.max(res, dp[i]);
        }
        return res;
    }
}

2.2 求可行性

如果有这样一个问题，让你判断是否存在一条总和为 x 的路径（如果找到了，就是 True；如果找不到，自然就是 False），或者让你判断能否找到一条符合某种条件的路径，那么这类问题都可以归纳为求可行性问题，并且可以使用动态规划来解。

1. 凑零兑换问题

问题：给你 k 种面值的硬币，面值分别为 c1, c2 … ck，每种硬币的数量无限，再给一个总金额 amount，问你最少需要几枚硬币凑出这个金额，如果不可能凑出，算法返回 -1 。

示例1：
输入: c1=1, c2=2, c3=5, c4=7, amount = 15
输出: 3
解释: 11 = 7 + 7 + 1。


示例2：
输入: c1=3, amount =7
输出: -1
解释: 3怎么也凑不到7这个值。

这个问题显而易见，如果不可能凑出我们需要的金额（即 amount），最后算法需要返回 -1，否则输出可能的硬币数量。这是一个典型的求可行性的动态规划问题。

对于示例代码：

class Solution {
    public int coinChange(int[] coins, int amount) {
        if(coins.length == 0)
            return -1;
        //声明一个amount+1长度的数组dp，代表各个价值的钱包，第0个钱包可以容纳的总价值为0，其它全部初始化为无穷大
        //dp[j]代表当钱包的总价值为j时，所需要的最少硬币的个数
        int[] dp = new int[amount+1];
        Arrays.fill(dp,1,dp.length,Integer.MAX_VALUE);
        for (int coin : coins) {
            for (int j = coin; j <= amount; j++) {
                if(dp[j-coin] != Integer.MAX_VALUE) {
                    dp[j] = Math.min(dp[j], dp[j-coin]+1);
                }
            }
        }
        if(dp[amount] != Integer.MAX_VALUE)
            return dp[amount];
        return -1;
    }
}

2. 字符串交错组成问题

问题：给定三个字符串 s1, s2, s3, 验证 s3 是否是由 s1 和 s2 交错组成的。

示例1：
输入: s1="aabcc",s2 ="dbbca",s3="aadbbcbcac"
输出: true
解释: 可以交错组成。


示例2：
输入: s1="aabcc",s2="dbbca",s3="aadbbbaccc"
输出: false
解释:无法交错组成。

这个问题稍微有点复杂，但是我们依然可以通过子问题的视角，首先求解 s1 中某个长度的子字符串是否由 s2 和 s3 的子字符串交错组成，直到求解整个 s1 的长度为止，也可以看成一个包含子问题的最值问题。
对应示例代码：

class Solution {
    public boolean isInterleave(String s1, String s2, String s3) {
        int length = s3.length();
        // 特殊情况处理
        if(s1.isEmpty() && s2.isEmpty() && s3.isEmpty()) return true;
        if(s1.isEmpty()) return s2.equals(s3);
        if(s2.isEmpty()) return s1.equals(s3);
        if(s1.length() + s2.length() != length) return false;
 
        int[][] dp = new int[s2.length()+1][s1.length()+1];
        // 边界赋值
        for(int i = 1;i < s1.length()+1;i++){
            if(s1.substring(0,i).equals(s3.substring(0,i))){
                dp[0][i] = 1;
            }
        }
        for(int i = 1;i < s2.length()+1;i++){
            if(s2.substring(0,i).equals(s3.substring(0,i))){
                dp[i][0] = 1;
            }
        }
        
        for(int i = 2;i <= length;i++){
            // 遍历 i 的所有组成（边界除外）
            for(int j = 1;j < i;j++){
                // 防止越界
                if(s1.length() >= j && i-j <= s2.length()){
                    if(s1.charAt(j-1) == s3.charAt(i-1) && dp[i-j][j-1] == 1){
                        dp[i-j][j] = 1;
                    }
                }
                // 防止越界
                if(s2.length() >= j && i-j <= s1.length()){
                    if(s2.charAt(j-1) == s3.charAt(i-1) && dp[j-1][i-j] == 1){
                        dp[j][i-j] = 1;
                    }
                }
            }
        }
        return dp[s2.length()][s1.length()]==1;
    }
}

2.3 求总数

除了求最值与可行性之外，求方案总数也是比较常见的一类动态规划问题。比如说给定一个数据结构和限定条件，让你计算出一个方案的所有可能的路径，那么这种问题就属于求方案总数的问题。

1. 硬币组合问题

问题：英国的英镑硬币有 1p, 2p, 5p, 10p, 20p, 50p, £1 (100p), 和 £2 (200p)。比如我们可以用以下方式来组成 2 英镑：1×£1 + 1×50p + 2×20p + 1×5p + 1×2p + 3×1p。问题是一共有多少种方式可以组成 n 英镑? 注意不能有重复，比如 1 英镑 +2 个 50P 和 50P+50P+1 英镑是一样的。

示例1：
输入: 2
输出: 73682 

这个问题本质还是求满足条件的组合，只不过这里不需要求出具体的值或者说组合，只需要计算出组合的数量即可。

public class Main {
    public static void main(String[] args) throws Exception {
        
        Scanner sc = new Scanner(System.in);
        while (sc.hasNext()) {
            
            int n = sc.nextInt();
            int coin[] = { 1, 5, 10, 20, 50, 100 };
            
            // dp[i][j]表示用前i种硬币凑成j元的组合数
            long[][] dp = new long[7][n + 1];
            
            for (int i = 1; i <= n; i++) {
                dp[0][i] = 0; // 用0种硬币凑成i元的组合数为0
            }
            
            for (int i = 0; i <= 6; i++) {
                dp[i][0] = 1; // 用i种硬币凑成0元的组合数为1,所有硬币均为0个即可
            }
            
            for (int i = 1; i <= 6; i++) {
                
                for (int j = 1; j <= n; j++) {
                    
                    dp[i][j] = 0;
                    for (int k = 0; k <= j / coin[i - 1]; k++) {
                        
                        dp[i][j] += dp[i - 1][j - k * coin[i - 1]];
                    }
                }
            }
            
            System.out.print(dp[6][n]);
        }
        sc.close();
    }
}

2. 路径规划问题

问题：一个机器人位于一个 m x n 网格的左上角。机器人每次只能向下或者向右移动一步。机器人试图达到网格的右下角，共有多少路径？

示例1：
输入: 2 2
输出: 2


示例1：
输入: 3 3
输出: 6

这个问题还是一个求满足条件的组合数量的问题，只不过这里的组合变成了路径的组合。我们可以先求出长宽更小的网格中的所有路径，然后再在一个更大的网格内求解更多的组合。这和硬币组合的问题相比没有什么本质区别。

这里有一个规律或者说现象需要强调，那就是求方案总数的动态规划问题一般都指的是求“一个”方案的所有具体形式。如果是求“所有”方案的具体形式，那这种肯定不是动态规划问题，而是使用传统递归来遍历出所有方案的具体形式。

为什么这么说呢？因为你需要把所有情况枚举出来，大多情况下根本就没有重叠子问题给你优化。即便有，你也只能使用备忘录对遍历进行一个简单加速。但本质上，这类问题不是动态规划问题。

对应示例代码：

package com.qst.Tesst;

import java.util.Scanner;

public class Test12 {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        while (scanner.hasNext()) {
            int x = scanner.nextInt();
            int y = scanner.nextInt();

            //设置路径
            long[][] path = new long[x + 1][y + 1];
            //设置领导数量
            int n = scanner.nextInt();

            //领导位置
            for (int i = 0; i < n; i++) {
                int a = scanner.nextInt();
                int b = scanner.nextInt();
                path[a][b] = -1;
            }

            for (int i = 0; i <= x; i++) {
                path[i][0] = 1;
            }
            for (int j = 0; j <= y; j++) {
                path[0][j] = 1;
            }

            for (int i = 1; i <= x; i++) {
                for (int j = 1; j <= y; j++) {
                    if (path[i][j] == -1) {
                        path[i][j] = 0;
                    } else {
                        path[i][j] = path[i - 1][j] + path[i][j - 1];
                    }

                }

            }
            System.out.println(path[x][y]);
        }
    }
}

三、 如何确认动态规划问题

从前面我所说来看，如果你碰到了求最值、求可行性或者是求方案总数的问题的话，那么这个问题就八九不离十了，你基本可以确定它就需要使用动态规划来解。但是，也有一些个别情况需要注意：

3.1 数据不可排序

假设我们有一个无序数列，希望求出这个数列中最大的两个数字之和。很多初学者刚刚学完动态规划会走火入魔到看到最优化问题就想用动态规划来求解，事实上，这个问题不是简单做一个排序或者做一个遍历就可以求解出来的。对于这种问题，我们应该先考虑一下能不能通过排序来简化问题，如果不能，才极有可能是动态规划问题。

最小的 k 个数

问题：输入整数数组 arr ，找出其中最小的 k 个数。例如，输入 4、5、1、6、2、7、3、8 这 8 个数字，则最小的 4 个数字是 1、2、3、4。

示例1：
输入：arr = [3,2,1], k = 2
输出：[1,2] 或者 [2,1]


示例2：
输入：arr = [0,1,2,1], k = 1
输出：[0]

我们发现虽然这个问题也是求“最”值，但其实只要通过排序就能解决，所以我们应该用排序、堆等算法或者数据结构就可以解决，而不应该用动态规划。

对应的示例代码：

public class Solution {
    public ArrayList<Integer> GetLeastNumbers_Solution(int [] input, int k) {
                int t;
        boolean flag;
        ArrayList result = new ArrayList();
        if(k>input.length){
            return result;
        }
        for(int i =0;i<input.length;i++){
            flag = true;
            for(int j = 0; j < input.length-i;j++)
                if(j<input.length-i-1){
                    if(input[j] > input[j+1]) {
                        t = input[j];
                        input[j] = input[j+1];
                        input[j+1] = t;
                        flag = false;
                    }
                }
            if(flag)break;
        }
        for(int i = 0; i < k;i++){
            result.add(input[i]);
        }
        return  result;
    }
}

3.2 数据不可交换

还有一类问题，可以归类到我们总结的几类问题里去，但是不存在动态规划要求的重叠子问题（比如经典的八皇后问题），那么这类问题就无法通过动态规划求解。

全排列

问题：给定一个没有重复数字的序列，返回其所有可能的全排列。

示例：
输入: [1,2,3]
输出:
[
  [1,2,3],
  [1,3,2],
  [2,1,3],
  [2,3,1],
  [3,1,2],
  [3,2,1]
]

这个问题虽然是求组合，但没有重叠子问题，更不存在最优化的要求，因此可以使用回溯方法处理。

对应的示例代码：

public class Main {
    public static void main(String[] args) {
        perm(new int[]{1,2,3},new Stack<>());
    }
    public static void perm(int[] array, Stack<Integer> stack) {
        if(array.length <= 0) {
            //进入了叶子节点，输出栈中内容
            System.out.println(stack);
        } else {
            for (int i = 0; i < array.length; i++) {
                //tmepArray是一个临时数组，用于就是Ri
                //eg：1，2，3的全排列，先取出1，那么这时tempArray中就是2，3
                int[] tempArray = new int[array.length-1];
                System.arraycopy(array,0,tempArray,0,i);
                System.arraycopy(array,i+1,tempArray,i,array.length-i-1);
                stack.push(array[i]);
                perm(tempArray,stack);
                stack.pop();
            }
        }
    }
}

总结一下，哪些问题可以使用动态规划呢，通常含有下面情况的一般都可以使用动态规划来解决：

• 求最优解问题（最大值和最小值）；

• 求可行性（True 或 False）；

• 求方案总数；

• 数据结构不可排序（Unsortable）；

• 算法不可使用交换（Non-swappable）。

如果面试题目出现这些特征，那么在 90% 的情况下你都能断言它就是一个动归问题。除此之外，还需要考虑这个问题是否包含重叠子问题与最优子结构，在这个基础之上你就可以 99% 断言它是否为动归问题，并且也顺势找到了大致的解题思路。

来源：https://segmentfault.com/a/1190000041300090

那个谁，今天又写 bug 了，没错，他说的好像就是我。。。。。。

作为 Java 开发，我们在写代码的过程中难免会产生各种奇思妙想的 bug ，有些 bug 就挺让人无奈的，比如说各种空指针异常，在 ArrayList 的迭代中进行删除操作引发异常，数组下标越界异常等。

如果你不小心看到同事的代码出现了我所描述的这些 bug 后，那你就把我这篇文章甩给他！！！你甩给他一篇文章，并让他关注了一波 cxuan，你会收获他在后面像是如获至宝并满眼崇拜大神的目光。

废话不多说，下面进入正题。

错误一：Array 转换成 ArrayList

Array 转换成 ArrayList 还能出错？这是哪个笨。。。。。。

等等，你先别着急说，先来看看是怎么回事。

如果要将数组转换为 ArrayList，我们一般的做法会是这样

List<String> list = Arrays.asList(arr);

Arrays.asList() 将返回一个 ArrayList，它是 Arrays 中的私有静态类，它不是 java.util.ArrayList 类。如下图所示

Arrays 内部的 ArrayList 只有 set、get、contains 等方法，但是没有能够像是 add 这种能够使其内部结构进行改变的方法，所以 Arrays 内部的 ArrayList 的大小是固定的。

如果要创建一个能够添加元素的 ArrayList ，你可以使用下面这种创建方式：

ArrayList<String> arrayList = new ArrayList<String>(Arrays.asList(arr));

因为 ArrayList 的构造方法是可以接收一个 Collection 集合的，所以这种创建方式是可行的。

错误二：检查数组是否包含某个值

检查数组中是否包含某个值，部分程序员经常会这么做：

Set<String> set = new HashSet<String>(Arrays.asList(arr));
return set.contains(targetValue);

这段代码虽然没错，但是有额外的性能损耗，正常情况下，不用将其再转换为 set，直接这么做就好了：

return Arrays.asList(arr).contains(targetValue);

或者使用下面这种方式（穷举法，循环判断）

for(String s: arr){
 if(s.equals(targetValue))
  return true;
}
return false;

上面第一段代码比第二段更具有可读性。

错误三：在 List 中循环删除元素

这个错误我相信很多小伙伴都知道了，在循环中删除元素是个禁忌，有段时间内我在审查代码的时候就喜欢看团队的其他小伙伴有没有犯这个错误。

说到底，为什么不能这么做（集合内删除元素）呢？且看下面代码

ArrayList<String> list = new ArrayList<String>(Arrays.asList("a", "b", "c", "d"));
for (int i = 0; i < list.size(); i++) {
 list.remove(i);
}
System.out.println(list);

这个输出结果你能想到么？是不是蠢蠢欲动想试一波了？

答案其实是 [b,d]

为什么只有两个值？我这不是循环输出的么？

其实，在列表内部，当你使用外部 remove 的时候，一旦 remove 一个元素后，其列表的内部结构会发生改变，一开始集合总容量是 4，remove 一个元素之后就会变为 3，然后再和 i 进行比较判断。。。。。。所以只能输出两个元素。

你可能知道使用迭代器是正确的 remove 元素的方式，你还可能知道 for-each 和 iterator 这种工作方式类似，所以你写下了如下代码

ArrayList<String> list = new ArrayList<String>(Arrays.asList("a", "b", "c", "d"));
 
for (String s : list) {
 if (s.equals("a"))
  list.remove(s);
}

然后你充满自信的 run xxx.main() 方法，结果。。。。。。ConcurrentModificationException

为啥呢？

那是因为使用 ArrayList 中外部 remove 元素，会造成其内部结构和游标的改变。

在阿里开发规范上，也有不要在 for-each 循环内对元素进行 remove/add 操作的说明。

所以大家要使用 List 进行元素的添加或者删除操作，一定要使用迭代器进行删除。也就是

ArrayList<String> list = new ArrayList<String>(Arrays.asList("a", "b", "c", "d"));
Iterator<String> iter = list.iterator();
while (iter.hasNext()) {
 String s = iter.next();
 
 if (s.equals("a")) {
  iter.remove();
 }
}

.next() 必须在 .remove() 之前调用。在 foreach 循环中，编译器会在删除元素的操作后调用 .next()，导致ConcurrentModificationException。

错误四：Hashtable 和 HashMap

这是一条算法方面的规约：按照算法的约定，Hashtable 是数据结构的名称，但是在 Java 中，数据结构的名称是 HashMap，Hashtable 和 HashMap 的主要区别之一就是 Hashtable 是同步的，所以很多时候你不需要 Hashtable ，而是使用 HashMap。

错误五：使用原始类型的集合

这是一条泛型方面的约束：

在 Java 中，原始类型和无界通配符类型很容易混合在一起。以 Set 为例，Set 是原始类型，而 Set<?> 是无界通配符类型。

比如下面使用原始类型 List 作为参数的代码：

public static void add(List list, Object o){
 list.add(o);
}
public static void main(String[] args){
 List<String> list = new ArrayList<String>();
 add(list, 10);
 String s = list.get(0);
}

这段代码会抛出 java.lang.ClassCastException 异常，为啥呢？

使用原始类型集合是比较危险的，因为原始类型会跳过泛型检查而且不安全，Set、Set<?> 和 Set<Object> 存在巨大的差异，而且泛型在使用中很容易造成类型擦除。

大家都知道，Java 的泛型是伪泛型，这是因为 Java 在编译期间，所有的泛型信息都会被擦掉，正确理解泛型概念的首要前提是理解类型擦除。Java 的泛型基本上都是在编译器这个层次上实现的，在生成的字节码中是不包含泛型中的类型信息的，使用泛型的时候加上类型参数，在编译器编译的时候会去掉，这个过程成为类型擦除。

如在代码中定义List<Object>和List<String>等类型，在编译后都会变成List，JVM 看到的只是List，而由泛型附加的类型信息对 JVM 是看不到的。Java 编译器会在编译时尽可能的发现可能出错的地方，但是仍然无法在运行时刻出现的类型转换异常的情况，类型擦除也是 Java 的泛型与 C++ 模板机制实现方式之间的重要区别。

比如下面这段示例

public class Test {

    public static void main(String[] args) {

        ArrayList<String> list1 = new ArrayList<String>();
        list1.add("abc");

        ArrayList<Integer> list2 = new ArrayList<Integer>();
        list2.add(123);

        System.out.println(list1.getClass() == list2.getClass());
    }

}

在这个例子中，我们定义了两个ArrayList数组，不过一个是ArrayList<String>泛型类型的，只能存储字符串；一个是ArrayList<Integer>泛型类型的，只能存储整数，最后，我们通过list1对象和list2对象的getClass()方法获取他们的类的信息，最后发现结果为true。说明泛型类型String和Integer都被擦除掉了，只剩下原始类型。

所以，最上面那段代码，把 10 添加到 Object 类型中是完全可以的，然而将 Object 类型的 "10" 转换为 String 类型就会抛出类型转换异常。

错误六：访问级别问题

我相信大部分开发在设计 class 或者成员变量的时候，都会简单粗暴的直接声明 public xxx，这是一种糟糕的设计，声明为 public 就很容易赤身裸体，这样对于类或者成员变量来说，都存在一定危险性。

错误七：ArrayList 和 LinkedList

哈哈哈，ArrayList 是我见过程序员使用频次最高的工具类，没有之一。

当开发人员不知道 ArrayList 和 LinkedList 的区别时，他们经常使用 ArrayList（其实实际上，就算知道他们的区别，他们也不用 LinkedList，因为这点性能不值一提），因为看起来 ArrayList 更熟悉。。。。。。

但是实际上，ArrayList 和 LinkedList 存在巨大的性能差异，简而言之，如果添加/删除操作大量且随机访问操作不是很多，则应首选 LinkedList。如果存在大量的访问操作，那么首选 ArrayList，但是 ArrayList 不适合进行大量的添加/删除操作。

错误八：可变和不可变

不可变对象有很多优点，比如简单、安全等。但是不可变对象需要为每个不同的值分配一个单独的对象，对象不具备复用性，如果这类对象过多可能会导致垃圾回收的成本很高。在可变和不可变之间进行选择时需要有一个平衡。

一般来说，可变对象用于避免产生过多的中间对象。比如你要连接大量字符串。如果你使用一个不可变的字符串，你会产生很多可以立即进行垃圾回收的对象。这会浪费 CPU 的时间和精力，使用可变对象是正确的解决方案（例如 StringBuilder）。如下代码所示：

String result="";
for(String s: arr){
 result = result + s;
}

所以，正确选择可变对象还是不可变对象需要慎重抉择。

错误九：构造函数

首先看一段代码，分析为什么会编译不通过？

发生此编译错误是因为未定义默认 Super 的构造函数。在 Java 中，如果一个类没有定义构造函数，编译器会默认为该类插入一个默认的无参数构造函数。如果在 Super 类中定义了构造函数，在这种情况下 Super(String s)，编译器将不会插入默认的无参数构造函数。这就是上面 Super 类的情况。

要想解决这个问题，只需要在 Super 中添加一个无参数的构造函数即可。

public Super(){
    System.out.println("Super");
}

错误十：到底是使用 "" 还是构造函数

考虑下面代码：

String x = "abc";
String y = new String("abc");

上面这两段代码有什么区别吗？

可能下面这段代码会给出你回答

String a = "abcd";
String b = "abcd";
System.out.println(a == b);  // True
System.out.println(a.equals(b)); // True
 
String c = new String("abcd");
String d = new String("abcd");
System.out.println(c == d);  // False
System.out.println(c.equals(d)); // True

这就是一个典型的内存分配问题。

后记

今天我给你汇总了一下 Java 开发中常见的 10 个错误，虽然比较简单，但是很容易忽视的问题，细节成就完美，看看你还会不会再犯了，如果再犯，嘿嘿嘿。

作者：cxuan
来源：https://mp.weixin.qq.com/s/uF0p8MGDhfvke4gdRv44iA

当地时间 1 月 18 日，Nginx 公司副总裁兼总经理 Rob Whiteley 在 Nginx 官网发布了一篇「告别信」，正式宣告 Nginx 的作者和 Nginx Inc. 的联合创始人 Igor Sysoev 退出 Nginx 和 F5 Networks。

此事很快登上 Hacker News 的热搜榜，有网友留言道：

我看过 Igor 参加某个会议的视频，他一说：“你好，我是 Nginx 的创建者 Igor Sysoev ”，观众席就会‘爆发’绵延不绝的掌声。他甚至不得不告诉他们“Come on guys, 你们还没听我的讲演呢。”。

不少开发者对 Igor 所做出的贡献表达了崇敬和感谢，也有网友感慨“巅峰一代落幕”。从 2002 年发展至今日，Nginx 已经成为全球最受欢迎的 Web 服务器。据 W3Techs 统计，截至 2022 年 1 月上旬，Nginx 占据了全球 Web 服务器市场 33% 的份额。排在第二位的是 Apache，份额为 31%。

一直以来，Nginx 常被拿来跟 Apache 对比，也有观点认为，Nginx 和 Apache 不算真正意义上的竞争者，很多地方会同时使用两者。但无论如何，Igor 和 Nginx 的成功确实鼓舞了不少开源人。

作为一名开源开发者和商业 OSS 初创公司创始人，Nginx 给了我很大的挑战现状的信心。Apache 是如此受人尊敬，以至于你会认为可以改进它的想法是很疯狂的，但他（ Igor ）做到了，这对我产生了真正的影响。——yesimahuman

Igor 早期曾在采访中分享对于开源和商业产品找平衡的观点，他表示不想创建单独的商业产品，而是希望对 Nginx 的主要开源产品进行商业扩展，社区想要的新功能将出现在其中。商业扩展更多的是有助于处理数千个实例、添加扩展性能监控、托管、云和 CDN 基础设施的附加功能等。

很多客户会说愿意付钱让 Igor 增加他们所需要的新功能，而 Igor 等人收集此类请求后会将其与从用户社区收到的需求进行比较，并寻找交叉点——“如果我们意识到每个人都需要某些功能，而不仅仅是某些公司，我们会将这些功能包含在开源版本中。我们从中了解我们可以销售什么，而不会惹恼开源产品的支持者，也不会损害整个项目的信誉。”

Nginx 如今归属于 F5 Networks。2019 年 3 月，F5 Networks 宣布将以 6.7 亿美元收购 Nginx，根据交易条款，Nginx 品牌被保留，而 Igor 和 合伙人 Konovalov 作为 F5 的一部分继续致力于该项目。但这笔交易很快就触发了利益纷争，同年 12 月，Igor 陷入版权纠纷，前东家 Rambler 集团对 NGINX Inc. 提出了侵犯版权的诉讼，声称拥有 Nginx Web 服务器代码的全部所有权，但 Igor 辩称是在业余时间开发了 Nginx。

此事随即引发热议，业余项目究竟属于开发者个人、还是属于开发者所在的企业，目前没有明确的统一的法律来判定。2020 年 4 月，Rambler 驳回针对 Nginx 的刑事诉讼。但 Rambler 并未就此停下，只是不再是以刑事诉讼的方式，而是通过民事法院，并于 2020 年 6 月初宣布授权旗下 Lynwood Investments 在美国对 F5 Networks、Igor 本人发起民事诉讼，要求索赔 7.5 亿美元。6 月末，俄罗斯内政部因缺乏犯罪记录证据，结案了有关 Nginx 版权的案件。

告别信有提到 Igor 从 Nginx 离职后将从事个人项目，目前我们尚不清楚他具体会涉及哪些项目。

以下是「告别信」全文：

挥别 Igor：
感谢你为 Nginx 付出的一切

怀着深深的感激之情，我们今天宣布，Nginx 的作者和 Nginx 公司联合创始人 Igor Sysoev 选择退出 Nginx 和 F5，以便花更多的时间与他的朋友和家人在一起，并追求个人项目。

2002 年的春天，Igor Sysoev 开始开发 Nginx。互联网的早期飞速发展让他萌生出一个念头：用一套全新架构改进网络流量的处理方式，帮助高流量网站从容应对数万个并发连接，并将照片、视频等各类可能严重拖慢页面加载速度的内容统统塞进缓存。

二十年过去，Igor 写下的代码已经在为世界上大部分网站提供支持。除了直接使用外，也被作为 Cloudflare、OpenResty、Tengine 等流行服务器的底层软件。很多人认为，Igor 最初的梦想就是把 Web 塑造成如今的样貌。Igor 所秉持的意志与价值观则汇聚成 Nginx 公司，结合开源与技术社区之力成就高透明度、质量卓越的代码，最终转化为客户喜闻乐见的商业产品。

但其中的平衡往往很难把握。Igor 之所以受到开发者、企业客户以及 Nginx 工程师们的高度赞扬，依靠的正是他谦逊的内心、不断探索的激情以及在开发工作中勇攀高峰的意志。

Igor 的成长与 Nginx 的诞生

Igor 的人生起点不高。他出生于苏联时期的一个哈萨克斯坦小镇，父亲是一名军官。一岁时，他们全家迁往首都阿拉木图。Igor 从小痴迷计算机，1980 年代中期就在 Yamaha MSX 上写下了人生第一行代码。而伴随着早期互联网产业的快速发展，Igor 也从著名的鲍曼莫斯科国立技术大学计算机科学系顺利毕业。

Igor 毕业后先找了份系统管理员工作，但写代码的好习惯一直没有丢下。1999 年，他用汇编语言开发出自己的第一个程序，这款反病毒软件能抵御当时最常见的十种计算机病毒。Igor 免费开放了程序的二进制文件，这款工具也在俄罗斯国内风靡一时。之后，敏感的他发觉 Apache HTTP 服务器的连接处理方式过于原始，根本无法满足不断发展的万维网需求。于是他决定开展相关研究，这也正是后来 Nginx 项目的雏形。

彼时，Igor 将目光投向了 C10k 问题，即如何在单一服务器上处理 10000 个并发连接。此外，他还希望让自己的 Web 服务器更快、更高效地处理照片或者音乐文件等极占传输带宽的元素。在获得俄罗斯国内外多家公司的肯定和采用之后，Igor 于 2004 年 10 月 4 日（即苏联发射全球首颗人造卫星「斯普特尼克」号的四十七周年纪念日）对这个名为 Nginx 的项目进行了许可开源。

七年来，Igor 一直是唯一的开发者。他独力写下数十万行代码，并把 Nginx 从简单的 Web 服务器加反向代理工具，扩展成一把能满足各类 Web 应用与服务需求的“瑞士军刀”。随着项目发展，负载均衡、缓存、安全和内容加速等关键功能也在他的指尖一一成形。

没有队伍的 Igor 当时自然没精力宣传项目，甚至连说明文档也不够完备。但 Nginx 仍然凭借着出色的表现迅速占领了市场。更神奇的是，新用户发现就算没有全面的使用指南、自己仍然能轻松玩转 Nginx，于是项目就在口口相传之下普及开来。越来越多的开发者和系统管理员利用 Nginx 解决自己面对的现实问题，提升网站响应速度。对于 Igor 的贡献，我们已经不需要刻意赞美或者宣扬，他的代码已经说明了一切。

Nginx 开启商业化之路，但开源定位永不动摇

2011 年，Igor 与 Maxim Konovalov、Andrew Alexeev 两位联合创始人共同成立了 Nginx 公司，希望借众人之力加快项目开发速度。但 Igor 也很清楚，从这一刻起他和团队得想办法赚钱了。不过他们坚持发布 Nginx 完整开源版本、恪守开源许可的承诺不会动摇。君子一诺值千金，自公司成立以来，Igor 引领 Nginx 通过 140 多个版本不断完善自我，始终以开源姿态为全球数亿网站提供支持。

奔波在为 Nginx 公司筹集风险投资的路上——（右起）Igor、公司 CEO Gus Robertson、联合创始人 Andrew Alexeev 以及 Maxim Konovalov

2011 年的时候，以专有模块的形式向商业版本中添加新功能的想法还属于开时代之先河。但如今，很多开源后起之秀已经可以站在巨人的肩膀上享受这种商业模式。在商业版 Nginx Plus 于 2013 年首次推出时，市场立刻抱以热烈欢迎。四年之后，Nginx 已经拥有超过 1000 家付费客户和数千万收入，Nginx 开源项目与技术社区的规模也在同步发展壮大。截至 2019 年底，Nginx 已经在为全球超过 4.75 亿个网站提供支持；到 2021 年，Nginx 正式成为世界上应用范围最广的 Web 服务器方案。

着眼于未来需求，Igor 还一路打造出多个 Nginx 相关项目，包括 Nginx JavaScript（njs）与 Nginx Unit。他还为 sendfile（2）系统调用设计了全新实现，将其整合到开源 FreeBSD 操作系统当中。随着 Nginx 工程师队伍的壮大和 Nginx 公司正式加入 F5，Igor 一直是团队背后稳健的领导者，保证 Nginx 始终方向明确、斗志坚定。

接过 Igor 手中的旗帜

今天，Igor 希望退居幕后享受生活，独余我们继续前行。但 Igor 的精神和他一路塑造的文化不会消失。伟大的企业、产品和项目中，创始人的 DNA 是永恒不变的。我们对于产品、社区、透明度、开源和创新的态度皆继承自 Igor，我们也将继续在 Maxim 和 Nginx 领导团队的指引下接过这面旗帜、发挥这份传统。

Igor 在 Nginx 与 F5 时代的奋斗与付出凝结成了我们今天所看到的项目代码，多年以来一直默默支撑起整个互联网世界。时间会考验我们、鞭策我们，证明我们能否像 Igor 那样创造出历久弥新、影响深远的产品。这当然是一条极高的标准，但 Igor 也用实际行动为我们指明了达成目标的方法。感恩多年来的指引与教导，Igor，祝你在人生的新阶段写下新的传奇故事。

来源：https://mp.weixin.qq.com/s/GANdlnXt1_vuUm3j97Njg

当 前，城市数字孪生已经发展成为支撑智慧城市的重要技术手段。

全文共计3026字，预计阅读时间8分钟

来源| 全国信标委智慧城市标准工作组

编辑 | 蒲蒲

城市数字孪生通过在数字空间对城市物理空间和社会空间进行全要素表达、全过程呈现、全周期可溯，实现城市全面感知、虚实交互、智能决策、精准控制，推动城市智能化、智慧化发展。

当前，城市数字孪生已经发 展成为支撑智慧城市的重要技术手段。 为做好城市数字孪生标准化工作整体规划，有序推动相关标准制定与应用实施工作，全国信标 委智慧城市标准工作组组建了城市数字孪生专题组，并联合相关单位编制了《城市数字孪生标准化白皮书（2022版）》。

白皮书在系统研究城市数字孪生内涵、典型特征、相关方等基础上，构建了城市数字孪生技术参考架构，梳理了城市数字孪生关键技术和典型应用场景，总结了城市数字孪生发展现状、发展趋势、面临的问题与挑战及国际国内标准化现状。在此基础上，白皮书探索形成了“城市数字孪生标准体系总体框架（1.0版）”，并提出了拟研制标准建议和标准化工作建议。白皮书构建了城市数字孪生标准化路线图，为后续相关标准研制、应用实施指明了方向。

城市数字孪生典型特征

全面感知：城市数字孪生以全面感知为前提。城市是一个复杂巨系统，时刻处于发展变化中，必须时刻掌握物理城市的全局发展与精细变化，实现孪生环境下的数字城市与物理城市同步运行。

精准映射是构建数字世界并建立数字世界与物理世界紧密关系的过程。

智能推演是城市数字孪生具备智慧能力的体现，是实现对物理城市进行科学预测、指导与优化的关键。

动态可视：指通过将感知的多源数据进行数字化建模和可视化渲染，城市数字孪生提供了全要素、全范围、全精度真实的渲染效果，实现全空间信息和城市实时运行

虚实互动：指物理空间与数字空间的互操作和双向互动，借助物联网、图形/图像、AR/VR、人机交互等领域技术的协同和融合，实现城市级虚实空间融合、控制与反馈等能力。态势的动态展示。

协同演进是城市数字孪生具有高阶智慧能力的体现。城市数字孪生过程中，物理城市与数字城市在城市运行、数据、技术、机制等方面存在长期协同关系，长期相互反馈、相互影响。

多维度构建参考架构，立体刻画城市数字孪生内涵

白皮书对“城市数字孪生”概念进行了系统地梳理和分析，创新性地从概念、技术、相关方等不同视角构建了城市数字孪生参考架构。

白皮书认为，城市数字孪生是利用数字孪生技术，以数字化方式创建城市物理实体的虚拟映射，借助历史数据、实时数据、空间数据以及算法模型等，仿真、预测、交互、控制城市物理实体全生命周期过程的技术手段，可以实现城市物理空间和社会空间中物理实体对象以及关系、活动等在数字空间的多维映射和连接。

从概念视角，城市数字孪生以城市物理空间、社会空间以及数字空间在时间维度和空间维度更加精准的映射、更加紧密的联接和更加多维的联动，实现三元空间的协同演进和共生共智，满足“人”在城市生活、生产、生态的各类需求，服务“以人为本”的智慧城市建设初心。

图1 城市数字孪生概念模型

从技术视角，需对物理空间以及社会空间中的物理实体对象、事件对象以及关系对象进行数字空间的虚拟表达以及映射，通过信息基础设施的转化传输以及处理形成数据资源，在通用服务能力的支撑下进一步融合数字孪生技术形成能够对外提供的数字孪生服务，并通过交互服务实现与上层应用场景的融合。同时，需提供立体化安全管理以及全生命周期的运营管理，保障数字空间各类资产以及服务的安全高效运行。

图2 城市数字孪生技术参考架构

从相关方视角，城市数字孪生由城市数字孪生咨询服务提供方、建设技术提供方、运营服务方三方多类主体联动构建。

图3 城市数字孪生相关方

梳理发展现状，总结城市数字孪生趋势与问题

白皮书梳理了城市数字孪生国家及地方相关政策，分析了产业生态发展现状。同时，提出了城市数字孪生发展的总体发展趋势及面临的主要问题和挑战。

图4 城市数字孪生产业生态

随着各地城市数字孪生探索与落地，智慧城市建设也将进入新的发展阶段。随供需双发力，城市数字孪生的技术创新、产业发展、标准规范等将快速发展，呈现物理城市和数字城市并行共生的新发展格局。

• 城市数字孪生将成为智慧城市建设技术底座。城市数字孪生将成为智慧城市发展新阶段的核心底座，为城市构建虚实共生的数字基础设施能力。
• 城市数字孪生将在智慧城市中迎来深度应用。城市数字孪生相关产业快速发展，市场规模不断扩大，以城市大脑、城运中心、城市信息模型、城市数字孪生运营管理为主的相关领域市场迅速升温。
• 城市数字孪生将形成跨行业协作生态共融。数据融合、技术融合和业务融合推动城市数字孪生产业链上下游的多元主体在竞争中发展出共生关系，生态共融正成为行业共识。

城市数字孪生从概念培育逐步走向建设实施，各项支撑技术日渐成熟，但仍面临着供应链安全性不足、数据支撑不足、应用深度不足、产业联动不足和标准支撑不足等问题与挑战。

构建标准体系，以标准化助力高质量发展

当前，城市数字孪生标准化处于起步阶段，亟需开展标准体系顶层设计。白皮书探索构建了“城市数字孪生标准体系总体框架（1.0版）”，将城市数字孪生标准划分为“01总体”“02数据”“03技术与平台”“04安全”“05运维/运营”“06应用”六大类。

图5 城市数字孪生标准体系总体框架（1.0版）

图6 城市数字孪生标准体系结构

为充分发挥标准基础性、引领性作用，助力城市数字孪生相关产业高质量发展，白皮书建议城市数字孪生标准化工作主要从四方面开展。

• 完善工作机制，强化统筹与协同。城市数字孪生涉及技术、应用、相关方众多，是复杂的系统工程，其标准化工作开展需统筹布局、协同各方。
• 研制重点标准，完善标准体系建设。以“规划引领、需求牵引”为原则，推动重点标准研制工作，不断完善城市数字孪生标准体系。
• 挖掘优秀案例，发挥示范引领作用。建立城市数字孪生典型案例与标准的良性互动机制，充分发挥先进性、代表性案例的引领与示范作用。
• 强化国际交流，推动国际标准制定。城市数字孪生承载了一系列关键技术和核心产业，要借助国际标准带动我国产品和方案走出去。

下一步，全国信标委智慧城市标准工作组将以此白皮书为基础，与各界共同推动城市数字孪生技术、理论、标准研究与制定工作，凝共识、聚合力，助力城市数字孪生产业生态培育，推动“以人为本”的智慧城市向智能化、智慧化迈进。

具体内容如下

来源：全国信标委智慧城市标准工作组    

本文介绍策略模式的具体应用以及Map+函数式接口如何 “更完美” 的解决 if-else的问题。

需求

最近写了一个服务：根据优惠券的类型resourceType和编码resourceId来 查询 发放方式grantType和领取规则

实现方式：

1. 根据优惠券类型resourceType -> 确定查询哪个数据表

2. 根据编码resourceId -> 到对应的数据表里边查询优惠券的派发方式grantType和领取规则

优惠券有多种类型，分别对应了不同的数据库表：

• 红包 —— 红包发放规则表

• 购物券 —— 购物券表

• QQ会员

• 外卖会员

实际的优惠券远不止这些，这个需求是要我们写一个业务分派的逻辑

第一个能想到的思路就是if-else或者switch case：

switch(resourceType){

case "红包": 
查询红包的派发方式 
break;
case "购物券": 
查询购物券的派发方式
break;
case "QQ会员" :
break;
case "外卖会员" :
break;
......
default : logger.info("查找不到该优惠券类型resourceType以及对应的派发方式");
break;
}

如果要这么写的话， 一个方法的代码可就太长了，影响了可读性。（别看着上面case里面只有一句话，但实际情况是有很多行的）

而且由于 整个 if-else的代码有很多行，也不方便修改，可维护性低。

策略模式

策略模式是把 if语句里面的逻辑抽出来写成一个类，如果要修改某个逻辑的话，仅修改一个具体的实现类的逻辑即可，可维护性会好不少。

以下是策略模式的具体结构(详细可看这篇博客： 策略模式.)：

策略模式在业务逻辑分派的时候还是if-else，只是说比第一种思路的if-else 更好维护一点。。。

switch(resourceType){

case "红包": 
String grantType=new Context(new RedPaper()).ContextInterface();
break;
case "购物券": 
String grantType=new Context(new Shopping()).ContextInterface();
break;

......
default : logger.info("查找不到该优惠券类型resourceType以及对应的派发方式");
break;

但缺点也明显：

• 如果 if-else的判断情况很多，那么对应的具体策略实现类也会很多，上边的具体的策略实现类还只是2个，查询红包发放方式写在类RedPaper里边，购物券写在另一个类Shopping里边；那资源类型多个QQ会员和外卖会员，不就得再多写两个类？有点麻烦了

• 没法俯视整个分派的业务逻辑

Map+函数式接口

用上了Java8的新特性lambda表达式

• 判断条件放在key中

• 对应的业务逻辑放在value中

这样子写的好处是非常直观，能直接看到判断条件对应的业务逻辑

需求： 根据优惠券(资源)类型resourceType和编码resourceId查询派发方式grantType

上代码：

@Service
public class QueryGrantTypeService {

   @Autowired
   private GrantTypeSerive grantTypeSerive;
   private Map<String, Function<String,String>> grantTypeMap=new HashMap<>();

   /**
    * 初始化业务分派逻辑,代替了if-else部分
    * key: 优惠券类型
    * value: lambda表达式,最终会获得该优惠券的发放方式
    */
   @PostConstruct
   public void dispatcherInit(){

       grantTypeMap.put("红包",resourceId->grantTypeSerive.redPaper(resourceId));
       grantTypeMap.put("购物券",resourceId->grantTypeSerive.shopping(resourceId));
       grantTypeMap.put("qq会员",resourceId->grantTypeSerive.QQVip(resourceId));
  }

   public String getResult(String resourceType){
  
    
    
       //Controller根据 优惠券类型resourceType、编码resourceId 去查询 发放方式grantType
       Function<String,String> result=getGrantTypeMap.get(resourceType);
       if(result!=null){

      //传入resourceId 执行这段表达式获得String型的grantType
           return result.apply(resourceId);
      }
       return "查询不到该优惠券的发放方式";
  }
}

如果单个 if 语句块的业务逻辑有很多行的话，我们可以把这些 业务操作抽出来，写成一个单独的Service，即：

//具体的逻辑操作

@Service
public class GrantTypeSerive {

   public String redPaper(String resourceId){

       //红包的发放方式
       return "每周末9点发放";
  }
   public String shopping(String resourceId){

       //购物券的发放方式
       return "每周三9点发放";
  }
   public String QQVip(String resourceId){

       //qq会员的发放方式
       return "每周一0点开始秒杀";
  }
}

入参String resourceId是用来查数据库的，这里简化了，传参之后不做处理。

用http调用的结果：

@RestController
public class GrantTypeController {

   @Autowired
   private QueryGrantTypeService queryGrantTypeService;

   @PostMapping("/grantType")
   public String test(String resourceName){

       return queryGrantTypeService.getResult(resourceName);
  }
}

用Map+函数式接口也有弊端：
你的队友得会lambda表达式才行啊，他不会让他自己百度去

最后捋一捋本文讲了什么：

1. 策略模式通过接口、实现类、逻辑分派来完成，把 if语句块的逻辑抽出来写成一个类，更好维护。

2. Map+函数式接口通过Map.get(key)来代替 if-else的业务分派，能够避免策略模式带来的类增多、难以俯视整个业务逻辑的问题。

   ————————————————
   作者：zhongh Jim
   来源：https://blog.csdn.net/qq_44384533/article/details/109197926

名词解释

在DDD兴起的原因以及与微服务的关系中曾举了一个研究桃树的例子，如果要研究桃树，将桃树根据器官分成根、茎、叶、花、果实、种子，这每一种器官都可以认为是一个研究领域,而领域又有更加具体的细分,分成子域、核心域、通用域、支撑域等，下面回顾桃树这个例子

看上面这张图 ，如果研究桃树是我们的业务，那么如何更加快速有效的研究桃树呢？ 根据回忆，初中课本是这样研究的:

第一步: 确定研究的对象，即研究领域 ，这里是一棵桃树。

第二步: 根据研究对象的某些维度，对其进行进一步的拆分，例如拆分成器官，而器官又可以分成营养器官，生殖器官，其中营养器官包括根、茎、叶,生殖器官包括花、果实、种子,那么这些就是我们要研究的子域。

第三步: 现在就可以最子域进行划分了，找出核心域,通用域,支撑域,至于为什么要这么划分，后面再解释，当我们找到核心域之后，再各个子域进行深一步的划分，划分成组织，例如分成保护组织,营养组织,疏导组织，这就儿也可以理解成将领域继续划分为子域的过程。

第四步:对组织进行进一步的划分，可以分成细胞，例如根毛细胞、导管细胞等等

我们有没有必要继续拆分细胞呢？这个取决于我们研究的业务，例如在之前光学显微镜时，研究到细胞也就截止了，具体到其他业务，也是研究到某一步就不需要继续拆分，而这最小层次的领域，通常就是我们所说的实体，聚合、聚合根、实体以及值对象等内容会在后面深入了解。

下面归纳一下上面提到的几个名词的概念 :

领域： 往往就是业务的某一个部分 ， 例如电商的销售部分、物流部分、供应链部分等， 这些对于电商来说就是各个领域(模块)，领域主要作用就是用来驱动范围， DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。简言之，DDD 的领域就是这个边界内要解决的业务问题域。

子域：相对的一个概念， 我们可以将领域进行进一步的划分 ， 这时候就是子域， 甚至可以对子域继续划分形成 子子域(依旧叫子域)，就好比当我们研究植物时，如果研究的对象是桃树，那么果实根茎叶是领域，可是如果不仅仅要研究果实，还要研究组织甚至细胞，那么研究的就是果实的子域、组织的子域。

核心域：所有领域中最关键的部分 ， 什么意思呢， 就是最核心的部分， 对于业务来说， 核心域是企业根本竞争力， 也是创造利润里最关键的部分 ， 例如电商里面那么多领域， 最重要的是什么？ 就是销售系统， 无论你是2B还是2C， 还是PDD ，这些核心模块就是核心域。

通用域:除了核心域之外， 还需要自己做的一些领域， 例如鉴权、日志等， 特点是可能被多个领域公用的部分。

支撑域:系统中业务分析阶段最不重点关注的领域， 也就是非核心域非通用域的领域， 例如电商里面的支付、物流，仅仅是为了支撑业务的运转而存在， 甚至可以去购买别人的服务， 这类的领域就是支撑域。

需要注意的是，这些名词在实际的微服务设计和开发过程中不一定用得上，但是可以帮助理解DDD的核心设计思想以及理念，而这些思想和理念在实际的IT战略设计业务建模和微服务设计上都是可以借鉴的。

为什么要划分核心域、通用域、支撑域 ？

通过上面可以知道，决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。还有一种功能子域是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。

这三类子域相较之下，核心域是最重要的，我们下面讲目的的时候还会以核心域为例详细介绍。通用域和支撑域如果对应到企业系统，举例来说的话，通用域则是你需要用到的通用系统，比如认证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化。而支撑域则具有企业特性，但不具有通用性，例如数据代码类的数据字典等系统。

那么为什么要划分出这些新的名词呢？ 先想一个问题,对于桃树而言，根、茎、叶、花、果实、种子六个领域哪一个是核心域？

是不是有不同的理解？ 有人说是种子，有人说是根，有人说是叶子，也有人说是茎等等，为什么会有这种情况呢？

因为每个人站的角度不一样，你如果是果农，那么果实就是核心域，你的大部分操作应该都是围绕提高果实产量进行，如果你是景区管理员，那么芳菲四月桃花盛开才是你重点关注，如果比是林场工作人员，那么树干才应该是你重点关注的领域，看到没，对于同一个领域划分的子域，每个人都有不同的理解，那么要通过讨论确定核心域，确保大家认同一致，对于实际业务开发来说，参与的人员众多，有业务方面的，有架构师，有后端开发人员，营销市场等等，势必要最开始就确定我们的核心域，除了统一大家的认识之外还有什么好处呢？

对于一个企业来说，预算以及时间是有限的，也就意味着时间以及精力甚至金钱要尽可能多的花在核心的的地方。就好比电商，电商企业那么多，每一家核心域都有所差别，造成的市场结果也千差万别,那么公司战略重点和商业模式应该找到核心域，且重点关注核心域。

总的来说，核心域、支撑域和通用域的主要目标是：通过领域划分，区分不同子域在公司内的不同功能
属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。

作者：等不到的口琴
来源：https://www.cnblogs.com/Courage129/p/14853600.html

如何保证外网开放接口的安全性。

• 使用加签名方式，防止数据篡改

• 信息加密与密钥管理

• 搭建OAuth2.0认证授权

• 使用令牌方式

• 搭建网关实现黑名单和白名单

一、令牌方式搭建搭建API开放平台

方案设计：

1.第三方机构申请一个appId,通过appId去获取accessToken,每次请求获取accessToken都要把老的accessToken删掉

2.第三方机构请求数据需要加上accessToken参数，每次业务处理中心执行业务前，先去dba持久层查看accessToken是否存在(可以把accessToken放到redis中，这样有个过期时间的效果)，存在就说明这个机构是合法，无需要登录就可以请求业务数据。不存在说明这个机构是非法的，不返回业务数据。

3.好处：无状态设计，每次请求保证都是在我们持久层保存的机构的请求，如果有人盗用我们accessToken，可以重新申请一个新的taken.

二、基于OAuth2.0协议方式

原理

第三方授权，原理和1的令牌方式一样

1.假设我是服务提供者A，我有开发接口，外部机构B请求A的接口必须申请自己的appid(B机构id)

2.当B要调用A接口查某个用户信息的时候，需要对应用户授权，告诉A，我愿同意把我的信息告诉B，A生产一个授权token给B。

3.B使用token获取某个用户的信息。

联合微信登录总体处理流程

1. 用户同意授权，获取code

2. 通过code换取网页授权access_token

3. 通过access_token获取用户openId

4. 通过openId获取用户信息

三、信息加密与密钥管理

• 单向散列加密

• 对称加密

• 非对称加密

• 安全密钥管理

1.单向散列加密

散列是信息的提炼，通常其长度要比信息小得多，且为一个固定长度。加密性强的散列一定是不可逆的，这就意味着通过散列结果，无法推出任何部分的原始信息。任何输入信息的变化，哪怕仅一位，都将导致散列结果的明显变化，这称之为雪崩效应。

散列还应该是防冲突的，即找不出具有相同散列结果的两条信息。具有这些特性的散列结果就可以用于验证信息是否被修改。

单向散列函数一般用于产生消息摘要，密钥加密等，常见的有：

• MD5（Message Digest Algorithm 5）：是RSA数据安全公司开发的一种单向散列算法，非可逆，相同的明文产生相同的密文。

• SHA（Secure Hash Algorithm）：可以对任意长度的数据运算生成一个160位的数值；

SHA-1与MD5的比较

因为二者均由MD4导出，SHA-1和MD5彼此很相似。相应的，他们的强度和其他特性也是相似，但还有以下几点不同：

• 对强行供给的安全性：最显著和最重要的区别是SHA-1摘要比MD5摘要长32 位。使用强行技术，产生任何一个报文使其摘要等于给定报摘要的难度对MD5是2128数量级的操作，而对SHA-1则是2160数量级的操作。这样，SHA-1对强行攻击有更大的强度。

• 对密码分析的安全性：由于MD5的设计，易受密码分析的攻击，SHA-1显得不易受这样的攻击。

• 速度：在相同的硬件上，SHA-1的运行速度比MD5慢。

1、特征：雪崩效应、定长输出和不可逆。

2、作用是：确保数据的完整性。

3、加密算法：md5（标准密钥长度128位）、sha1（标准密钥长度160位）、md4、CRC-32

4、加密工具：md5sum、sha1sum、openssl dgst。

5、计算某个文件的hash值，例如：md5sum/shalsum FileName,openssl dgst –md5/-sha

2.对称加密

秘钥：加密解密使用同一个密钥、数据的机密性双向保证、加密效率高、适合加密于大数据大文件、加密强度不高(相对于非对称加密)

对称加密优缺点

• 优点：与公钥加密相比运算速度快。

• 缺点：不能作为身份验证，密钥发放困难

DES是一种对称加密算法,加密和解密过程中，密钥长度都必须是8的倍数

public class DES {
 public DES() {
 }
 
 // 测试
 public static void main(String args[]) throws Exception {
  // 待加密内容
  String str = "123456";
  // 密码，长度要是8的倍数 密钥随意定
  String password = "12345678";
  byte[] encrypt = encrypt(str.getBytes(), password);
  System.out.println("加密前:" +str);
  System.out.println("加密后:" + new String(encrypt));
  // 解密
  byte[] decrypt = decrypt(encrypt, password);
  System.out.println("解密后:" + new String(decrypt));
 }
 
 /**
  * 加密
  * 
  * @param datasource
  *            byte[]
  * @param password
  *            String
  * @return byte[]
  */
 public static byte[] encrypt(byte[] datasource, String password) {
  try {
   SecureRandom random = new SecureRandom();
   DESKeySpec desKey = new DESKeySpec(password.getBytes());
   // 创建一个密匙工厂，然后用它把DESKeySpec转换成
   SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");
   SecretKey securekey = keyFactory.generateSecret(desKey);
   // Cipher对象实际完成加密操作
   Cipher cipher = Cipher.getInstance("DES");
   // 用密匙初始化Cipher对象,ENCRYPT_MODE用于将 Cipher 初始化为加密模式的常量
   cipher.init(Cipher.ENCRYPT_MODE, securekey, random);
   // 现在，获取数据并加密
   // 正式执行加密操作
   return cipher.doFinal(datasource); // 按单部分操作加密或解密数据，或者结束一个多部分操作
  } catch (Throwable e) {
   e.printStackTrace();
  }
  return null;
 }
 
 /**
  * 解密
  * 
  * @param src
  *            byte[]
  * @param password
  *            String
  * @return byte[]
  * @throws Exception
  */
 public static byte[] decrypt(byte[] src, String password) throws Exception {
  // DES算法要求有一个可信任的随机数源
  SecureRandom random = new SecureRandom();
  // 创建一个DESKeySpec对象
  DESKeySpec desKey = new DESKeySpec(password.getBytes());
  // 创建一个密匙工厂
  SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");// 返回实现指定转换的
                   // Cipher
                   // 对象
  // 将DESKeySpec对象转换成SecretKey对象
  SecretKey securekey = keyFactory.generateSecret(desKey);
  // Cipher对象实际完成解密操作
  Cipher cipher = Cipher.getInstance("DES");
  // 用密匙初始化Cipher对象
  cipher.init(Cipher.DECRYPT_MODE, securekey, random);
  // 真正开始解密操作
  return cipher.doFinal(src);
 }
}
 
输出
 
加密前:123456
加密后:>p.72|
解密后:123456

3.非对称加密

非对称加密算法需要两个密钥：公开密钥（publickey:简称公钥）和私有密钥（privatekey:简称私钥）。

公钥与私钥是一对

• 公钥对数据进行加密，只有用对应的私钥才能解密

• 私钥对数据进行加密，只有用对应的公钥才能解密

过程：

• 甲方生成一对密钥，并将公钥公开，乙方使用该甲方的公钥对机密信息进行加密后再发送给甲方；

• 甲方用自己私钥对加密后的信息进行解密。

• 甲方想要回复乙方时，使用乙方的公钥对数据进行加密

• 乙方使用自己的私钥来进行解密。

• 甲方只能用其私钥解密由其公钥加密后的任何信息。

特点：

• 算法强度复杂

• 保密性比较好

• 加密解密速度没有对称加密解密的速度快。

• 对称密码体制中只有一种密钥，并且是非公开的，如果要解密就得让对方知道密钥。所以保证其安全性就是保证密钥的安全，而非对称密钥体制有两种密钥，其中一个是公开的，这样就可以不需要像对称密码那样传输对方的密钥了。这样安全性就大了很多

• 适用于：金融，支付领域

RSA加密是一种非对称加密

import javax.crypto.Cipher;
import java.security.*;
import java.security.interfaces.RSAPrivateKey;
import java.security.interfaces.RSAPublicKey;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;
import java.security.KeyFactory;
import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PrivateKey;
import java.security.PublicKey;
import org.apache.commons.codec.binary.Base64;
 
 
/**
 * RSA加解密工具类
 *
 * 
 */
public class RSAUtil {
 
 public static String publicKey; // 公钥
 public static String privateKey; // 私钥
 
 /**
  * 生成公钥和私钥
  */
 public static void generateKey() {
  // 1.初始化秘钥
  KeyPairGenerator keyPairGenerator;
  try {
   keyPairGenerator = KeyPairGenerator.getInstance("RSA");
   SecureRandom sr = new SecureRandom(); // 随机数生成器
   keyPairGenerator.initialize(512, sr); // 设置512位长的秘钥
   KeyPair keyPair = keyPairGenerator.generateKeyPair(); // 开始创建
   RSAPublicKey rsaPublicKey = (RSAPublicKey) keyPair.getPublic();
   RSAPrivateKey rsaPrivateKey = (RSAPrivateKey) keyPair.getPrivate();
   // 进行转码
   publicKey = Base64.encodeBase64String(rsaPublicKey.getEncoded());
   // 进行转码
   privateKey = Base64.encodeBase64String(rsaPrivateKey.getEncoded());
  } catch (NoSuchAlgorithmException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
 }
 
 /**
  * 私钥匙加密或解密
  * 
  * @param content
  * @param privateKeyStr
  * @return
  */
 public static String encryptByprivateKey(String content, String privateKeyStr, int opmode) {
  // 私钥要用PKCS8进行处理
  PKCS8EncodedKeySpec pkcs8EncodedKeySpec = new PKCS8EncodedKeySpec(Base64.decodeBase64(privateKeyStr));
  KeyFactory keyFactory;
  PrivateKey privateKey;
  Cipher cipher;
  byte[] result;
  String text = null;
  try {
   keyFactory = KeyFactory.getInstance("RSA");
   // 还原Key对象
   privateKey = keyFactory.generatePrivate(pkcs8EncodedKeySpec);
   cipher = Cipher.getInstance("RSA");
   cipher.init(opmode, privateKey);
   if (opmode == Cipher.ENCRYPT_MODE) { // 加密
    result = cipher.doFinal(content.getBytes());
    text = Base64.encodeBase64String(result);
   } else if (opmode == Cipher.DECRYPT_MODE) { // 解密
    result = cipher.doFinal(Base64.decodeBase64(content));
    text = new String(result, "UTF-8");
   }
 
  } catch (Exception e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
  return text;
 }
 
 /**
  * 公钥匙加密或解密
  * 
  * @param content
  * @param privateKeyStr
  * @return
  */
 public static String encryptByPublicKey(String content, String publicKeyStr, int opmode) {
  // 公钥要用X509进行处理
  X509EncodedKeySpec x509EncodedKeySpec = new X509EncodedKeySpec(Base64.decodeBase64(publicKeyStr));
  KeyFactory keyFactory;
  PublicKey publicKey;
  Cipher cipher;
  byte[] result;
  String text = null;
  try {
   keyFactory = KeyFactory.getInstance("RSA");
   // 还原Key对象
   publicKey = keyFactory.generatePublic(x509EncodedKeySpec);
   cipher = Cipher.getInstance("RSA");
   cipher.init(opmode, publicKey);
   if (opmode == Cipher.ENCRYPT_MODE) { // 加密
    result = cipher.doFinal(content.getBytes());
    text = Base64.encodeBase64String(result);
   } else if (opmode == Cipher.DECRYPT_MODE) { // 解密
    result = cipher.doFinal(Base64.decodeBase64(content));
    text = new String(result, "UTF-8");
   }
  } catch (Exception e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
  return text;
 }
 
 // 测试方法
 public static void main(String[] args) {
  /**
   * 注意： 私钥加密必须公钥解密 公钥加密必须私钥解密
   *  // 正常在开发中的时候,后端开发人员生成好密钥对，服务器端保存私钥 客户端保存公钥
   */
  System.out.println("-------------生成两对秘钥，分别发送方和接收方保管-------------");
  RSAUtil.generateKey();
  System.out.println("公钥:" + RSAUtil.publicKey);
  System.out.println("私钥:" + RSAUtil.privateKey);
 
  System.out.println("-------------私钥加密公钥解密-------------");
   String textsr = "11111111";
   // 私钥加密
   String cipherText = RSAUtil.encryptByprivateKey(textsr,
   RSAUtil.privateKey, Cipher.ENCRYPT_MODE);
   System.out.println("私钥加密后：" + cipherText);
   // 公钥解密
   String text = RSAUtil.encryptByPublicKey(cipherText,
   RSAUtil.publicKey, Cipher.DECRYPT_MODE);
   System.out.println("公钥解密后：" + text);
 
  System.out.println("-------------公钥加密私钥解密-------------");
  // 公钥加密
  String textsr2 = "222222";
 
  String cipherText2 = RSAUtil.encryptByPublicKey(textsr2, RSAUtil.publicKey, Cipher.ENCRYPT_MODE);
  System.out.println("公钥加密后：" + cipherText2);
  // 私钥解密
  String text2 = RSAUtil.encryptByprivateKey(cipherText2, RSAUtil.privateKey, Cipher.DECRYPT_MODE);
  System.out.print("私钥解密后：" + text2 );
 }
 
}

四、使用加签名方式，防止数据篡改

客户端：请求的数据分为2部分（业务参数，签名参数），签名参数=md5（业务参数）

服务端：验证md5(业务参数)是否与签名参数相同
————————————————
作者：单身贵族男
来源：https://blog.csdn.net/zhou920786312/article/details/95536556

约翰·冯·诺依曼是20世纪最有影响力的人物之一。从原子弹，到计算机、再到量子力学、气候变化，你可能很难出对我们今天的世界和生活影响更大的科学家了。

神童降世

约翰·冯·诺依曼于1903年12月28日出生在匈牙利首都布达佩斯。 冯·诺依曼的父亲是银行家，母亲是奥匈贵族的女儿，他的父母富有且受人尊敬。

1913年，奥匈帝国皇帝弗朗茨·约瑟夫授予冯·诺依曼的父亲贵族地位，并给了这个家族一个世袭的头衔「马吉塔」，即现在的罗马尼亚马吉塔。 这个头衔纯粹是尊称，因为这个家庭与这个地方没有任何联系，但这是冯·诺依曼一生都会坚持的。 年轻的冯·诺依曼在同龄人中，被认为是真正的神童，尤其是在数学方面。人们认为他有摄影一般的记忆力，这帮助他从很小的时候就吸收了大量的知识。 冯·诺伊曼11岁时与表妹 Katalin Alcsuti在一起 六岁时，他就开始在头脑中进行两个八位数的除法，八岁时，他已经掌握了微积分。 他的父亲认为，他所有的孩子都需要说除母语匈牙利语以外的欧洲主要语言，所以冯·诺依曼学习了英语、法语、意大利语和德语。 小时候，他对历史也有很深的兴趣，并阅读了德国历史学家威廉·昂肯的整部46卷专著《通史》。

德国历史学家威廉·昂肯 在老师的鼓励下，冯·诺依曼在学习上取得了优异的成绩，但他的父亲不相信数学家的职业会带来经济上的利益。 相反，冯·诺依曼和他的父亲达成共识，同意冯·诺依曼从事化学工程，他17岁去柏林学习，后来在苏黎世学习。 化学似乎是冯·诺依曼少数几个不感兴趣的领域之一，尽管他确实获得了苏黎世化学工程文凭，同时还获得了数学博士学位。

职业生涯早期

约翰·冯·诺依曼很早就发表了论文，从20岁开始，他写了一篇定义序数的论文，这仍然是我们今天使用的定义。 他写了关于集合论的博士论文，并在一生中对该领域做出了若干贡献。
到1927年，冯·诺依曼已经发表了12篇著名的数学论文。到1929年，他已经出版了32部作品，以大约一个月一篇学术论文的速度写出了很多重要的工作。 1928年，他成为柏林大学的一名私 人教师，也是柏林大学历史上获得该职位最年轻的人。 这个职位使他能够在大学里讲课，直到1929年他成为汉堡大学的一名私人教师。 冯·诺依曼在父亲于1929年去世后，皈依了天主教。1930年元旦，约翰·冯·诺依曼与布达佩斯大学经济学学生玛丽埃塔·科维西结婚，并于1935年与她生下了他唯一的孩子玛丽娜。 虽然冯·诺依曼似乎注定要在德国科学院从事一个有前途的职业，但在1929年10月，他获得了新泽西州普林斯顿大学的一个职位，他最终接受了这个职位，并于1930年与妻子一起前往美国。

移民美国

到1933年，约翰·冯·诺依曼成为新成立的普林斯顿高等研究院最初的六名数学教授之一，他也将在这个岗位上度过余生。 当他搬到新泽西时，像他之前的许多美国移民一样，冯·诺依曼将他的匈牙利名字英语化了（由玛吉塔伊·诺依曼·亚诺斯变成约翰·冯·诺依曼，使用德国式的世袭尊称）。 1937年，他和妻子离婚，第二年冯·诺依曼再婚，这次是和克拉拉·丹，他在第二次世界大战前最后一次访问匈牙利时，在布达佩斯第一次见到了克拉拉·丹。 1937年，冯·诺依曼成为美国公民，1939年，他的母亲、兄弟姐妹和姻亲也都移民到了美国（他的父亲早些时候去世了）。

战争年代与「曼哈顿计划」

约翰·冯·诺依曼对历史最重要的贡献之一是他在第二次世界大战期间对曼哈顿计划的研究。 一如既往，冯·诺依曼不能让数学挑战得不到解决，更困难的问题之一是如何模拟爆炸的影响。 冯·诺依曼在20世纪30年代投身于这些问题的研究，并成为该领域的专家。如果他有特长的话，那应该是研究聚能装药（Shaped Charges，用于爆破）领域的数学问题，聚能装药是用来控制和引导爆炸能量的。 这使他与美国军方，特别是美国海军进行了相当多的定期磋商。当曼哈顿计划在20世纪40年代初开始工作时，冯·诺依曼因其专业知识而被招募。 1943年，冯·诺依曼对曼哈顿计划产生了最重大、最持久的影响。 曼哈顿计划成员 当时，设计原子弹的洛斯阿拉莫斯实验室发现，钚-239（该项目使用的裂变材料之一）与实验室的工作炸弹设计不兼容。 实验室的物理学家塞斯·尼德迈尔一直在研究一种独立的内爆型炸弹设计，这种设计很有希望，但许多人认为它不可行。

核弹内爆机制的动画 要引爆核爆炸，需要在炸弹的反应物中引发失控的裂变链式反应。链式反应的速度是指数级的，因此控制爆炸足够长的时间，使足够的裂变材料进行所需的反应，是一项重大挑战。 内爆型炸弹需要更复杂的控制来产生反应，但它也不需要像洛斯阿拉莫斯开发的枪型炸弹设计那样耗费那么多的材料。 内爆型装置使用一系列受控的常规爆炸来压缩其核心中的裂变反应物。 在这种压力下，裂变材料迅速开始核裂变链式反应，通过内爆的力量保持在原位，并允许更多的裂变材料释放其能量。

控制这些爆炸以产生精确的内爆力来产生期望的反应是一项很大的挑战，而冯·诺依曼以极大的热情接受了它。 他认为，使用较少的球形材料并通过内爆力适当压缩，可以产生更有效的爆炸，尽可能多地使用现有的裂变材料。 他经常是少数几个主张内爆方法的人之一，并最终计算出了一个数学公式，表明如果内爆能以至少95%的精度保持球形的几何形状，该方法就是可以实现的。 冯·诺依曼还计算出，如果爆炸在目标上方一定距离引爆，而不是在击中地面时引爆，爆炸的有效性将会提高。 这大大增加了原子弹的杀伤力，也减少了爆炸产生的尘埃量。 之后，冯·诺依曼被选为科学顾问团队的一员，他们就炸弹的可能目标咨询军方。 冯·诺依曼建议将目标定为日本京都，因为京都作为文化之都，其毁灭可能足以迫使战争迅速结束。 提出这一建议的不止他一个人，但战争部长亨利·史汀生否决了将目标对准京都这个提议，因为那里有许多历史建筑和重要的宗教圣地，所以最后选择了广岛和长崎。 1945年7月16日的三位一体试验中，冯·诺依曼在场，当时第一枚原子武器被引爆。广岛和长崎被炸后，日本投降，第二次世界大战结束。 三位一体试验 与曼哈顿计划中同时代的一些人不同，冯·诺依曼似乎没有任何反思的痛苦、遗憾，甚至对他在原子弹方面的工作也没有一丝怀疑。 事实上，冯·诺依曼是核武器发展和相互保证毁灭（MAD）理论的最有力支持者之一，认为这是防止另一场灾难性世界大战的唯一方法。

核武器的「轻量化」思想

像战后初期的许多美国人一样，冯·诺依曼担心美国在核武器发展方面落后于苏联。 到上世纪40 年代末到50 年代初，用战略轰炸机向敌人投掷更多原子弹的理念，逐渐被新的火箭技术所取代。
冯·诺依曼认为，导弹是核武器的未来，由于他与参与苏联武器研制的德国科学家有过接触，他知道苏联对此问题的看法与他是一样的。 军备竞赛开始了，美苏两国把氢弹越做越小，可以装入洲际弹道导弹的弹头，冯·诺依曼积极为美国效力，努力缩小与苏联的「导弹差距」。 战后，冯·诺依曼在原子能委员会任职，为政府和军方提供核技术开发和战略方面的建议，并被广泛认为是「确保相互毁灭」理论（MAD）的设计者，而 MAD 在冷战期间确实被政府采纳，成为事实上的美国国策。

建造第一台真正的计算机

冯·诺依曼在上世纪30年代初遇到了艾伦·图灵，当时图灵正在普林斯顿攻读博士学位。1937年，图灵发表了具有里程碑意义的论文《论可计算数》，奠定了现代计算的理论基础。
冯·诺依曼很快认识到了图灵这一发现的重要性，并在30年代推动了计算机科学的发展。在普林斯顿大学，他和图灵围绕人工智能的思想曾进行了长时间的讨论。 作为一名数学家，冯·诺依曼从更抽象的角度研究计算机科学，另一个原因也是因为在30年代时，并没有真正可以工作的计算机。 在二战结束后，这种情况很快就改变了。 冯·诺依曼深入参与了第一台可编程电子计算机「ENIAC」的开发，这台计算机能够识别和决定其他数据操作规则集，而不是最初使用的规则集。是冯诺依曼将 ENIAC 修改为作为存储程序机器运行。 后者让使我们今天理解的现代程序成为可能。冯·诺依曼本人编写了几个在 ENIAC 上运行的首批程序，并用这些程序模拟原子能委员会的部分核武器研究。 毫无疑问，冯·诺依曼对计算机科学领域最持久的贡献是在当今运行的每台计算机中使用的两个基本概念：冯·诺依曼体系架构和存储程序概念。 冯·诺依曼架构涉及构成计算机的物理电子电路的组织方式。按照这种方式构建的计算机被称为「冯·诺依曼机」。该架构由算术和逻辑单元 (ALU)、控制单元和临时存储器寄存器组成，它们共同构成了中央处理器 (CPU)。 CPU 连接到内存单元，该内存单元包含将要由CPU处理和操作的所有数据。CPU还连接到输入和输出设备，以根据需要更改数据，并检索运行程序的结果。 自 1945 年冯诺依曼提出这一架构以来，直到今天，它基本上仍是当今大多数通用计算机的运行方式，几乎没有改变。 另一项重大创新与冯·诺依曼架构有关，即存储程序概念，也就是说，被操作或处理的数据，以及描述如何操纵和处理该数据的程序，都存储在计算机的内存中。 这两项相互交织的创新实现了图灵机的理论框架，实际上将它们变成了可以用来计算工资、火炮轨迹、游戏、互联网等几乎所有一切数据的机器。

对其他领域的杰出贡献

除了数学和计算机科学之外，冯·诺依曼一生都对其他几个领域也做出了重大贡献。
在早期的职业生涯中，冯·诺依曼为新兴的量子力学领域做出了重大贡献。 1932年，他和保罗·狄拉克在《量子力学的数学基础》一书中发表了狄拉克-冯·诺依曼公理，这是该领域的第一个完整的数学框架。在这本书中，他还提出了量子逻辑的形式系统，也是同类体系中的首创。 冯·诺依曼还将博弈论确立为一门严谨的数学学科，这无疑影响了他后来关于MAD理论的地缘政治战略工作。 冯·诺依曼的博弈论中包含这样一个观点，即在广泛的博弈类别中，总是有可能找到一个平衡，任何参与者都不应单方面偏离这个平衡。 在生命科学领域，冯·诺依曼对元胞自动机的自我复制进行了彻底的数学分析，主要是构造函数、正在构建的事物以及构造函数构建所讨论事物所遵循的蓝图之间的关系。该分析描述了一种自我复制的机器，它是在40年代设计的，没有使用计算机。 冯·诺依曼的数学造诣也惠及气候科学。1950年，他编写了第一个气候建模程序，并使用 ENIAC 使用数值数据进行了世界上第一个气象预测。 冯·诺依曼预计，全球变暖是人类活动的结果，他在1955年写道： 「工业燃烧煤和石油释放到大气中的二氧化碳，可能已经充分改变了大气的成分，导致全球普遍变暖约1华氏度。」 冯·诺依曼也被认为是第一个描述「技术奇点」的人。冯·诺依曼的朋友斯坦·乌拉姆 (Stan Ulam) 后来描述了与他的一次对话，这次对话在今天听起来非常有先见之明。 斯坦·乌拉姆、理查德·费曼和冯·诺依曼在一起 乌拉姆回忆说：「有一次谈话集中在不断加速的技术进步和人类生活方式的变化上，这让我们看到了人类历史上一些本质上的奇点。一旦超越了这些奇点，我们所熟知的人类事务就将无法继续下去了。」

冯·诺依曼的去世，和他的光辉遗产

1955 年，冯·诺依曼在看医生时发现他的锁骨上长了一块肉，他被诊断患有癌症，但他并没有充分接受这个事实。 众所周知，冯·诺依曼对即将到来的结局感到恐惧。他的一生好友尤金·维格纳 (Eugene Wigner) 写道：
「当冯·诺依曼意识到自己病入膏肓时，他的逻辑迫使他意识到，自己即将不复存在，因此也不再有思想……亲眼目睹这一过程是令人心碎的，所有的希望都消失了，即将到来的命运尽管难以接受，但已经不可避免。」 冯·诺依曼的病情在1956年持续恶化，最终被送进了华盛顿特区的沃尔特里德陆军医疗中心。为防止泄密，军方对他实施了特殊的安全措施。 冯·诺依曼邀请一位天主教神父在他临终前商量，并接受了他的临终仪式安排。不过这位神父本人表示，冯诺依曼看上去似乎并没有从仪式中得到安慰。 1957年2月8日，冯·诺依曼因癌症逝世，享年53岁，他被安葬在新泽西州的普林斯顿公墓。 关于冯·诺依曼的癌症是否与他在「曼哈顿计划」期间遭受辐射有关，人们一直存在争议，但毫无争议的是，人类过早地失去了当代最伟大的科学巨人之一。 冯·诺依曼的助手 P.R. Halmos 在1973年写道： 「人类的英雄有两种：一种和我们所有人一样，但更加相似，另一种显然具有一些「超人」的特质。 我们都可以跑步，我们中的一些人可以在不到4分钟的时间内跑完一英里。但有些事，我们大多数人一辈子都无法做到。冯·诺依曼的伟大贡献是惠及全人类的。在某些时候，我们或多或少都能清晰地思考，但冯·诺依曼的清晰思维始终比我们大多数人高出好几个数量级。」 冯·诺依曼的才华是毋庸置疑的，尽管他留下的遗产，尤其是核武器方面的贡献，比他的朋友和崇拜者愿意承认的要复杂得多。 无论我们最终如何看待冯·诺依曼和他的成就，我们都可以肯定地说，在未来一代人甚至几代人的时间里，都不太可能出现像他一样，对人类历史产生如此重大影响的人了。

转自：新智元 | David 小咸鱼
原文链接：https://interestingengineering.com/john-von-neumann-human-the-computer-behind-project-manhattan

背景

之前的几篇文章都是关于低代码平台的。

这个大的项目以 low code 为核心，囊括了编辑器前端、编辑器后端、C 端 H5、组件库、组件平台、后台管理系统前端、后台管理系统后台、统计服务、自研 CLI 九大系统。

今天就来说一下其中的统计服务：目的主要是为了实现 H5 页面的分渠道统计(其实不仅仅是分渠道统计，核心是想做一个自定义事件统计服务，只是目前有分渠道统计的需求)，查看每个渠道具体的 PV 情况。(具体会在 url 上面体现，会带上页面名称、id、渠道类型等)

先放一下整体流程图吧：

日志收集

常见的日志收集方式有手动埋点和自动埋点，这里我们不关注于如何收集日志，而是如何将收集的日志的发送到服务器。

在常见的埋点方案中，通过图片来发送埋点请求是一种经常被采纳的，它有很多优势：

• 没有跨域

• 体积小

• 能够完成整个 HTTP 请求+响应（尽管不需要响应内容）

• 执行过程无阻塞

这里的方案就是在 nginx 上放一张 1px * 1px 的静态图片，然后通过访问该图片（http://xxxx.png?env=xx&event=xxx）,并将埋点数据放在query参数上，以此将埋点数据落到nginx日志中。

iOS 上会限制 get 请求的 url 长度，但我们这里真实场景发送的数据不会太多，所以目前暂时采用这种方案

这里简单阐述一下为什么图片地址的query key 要这么设计，如果单纯是为了统计渠道和作品，很有可能会把key设计为channel、workId这种，但上面也说到了，我们是想做一个自定义事件统计服务，那么就要考虑字段的可扩展性，字段应更有通用语义。所以参考了很多统计服务的设计，这里采用的字段为：

• env

• event

• key

• value

之后每次访问页面，nginx就会自动记录日志到access_log中。

有了日志，下面我们来看下如何来对其进行拆分。

日志拆分

为何要拆分日志

access.log日志默认不会拆分，会越积累越多，系统磁盘的空间会被消耗得越来越多，将来可能面临着日志写入失败、服务异常的问题。

日志文件内容过多，对于后续的问题排查和分析也会变得很困难。

所以日志的拆分是有必要也是必须的。

如何拆分日志

我们这里拆分日志的核心思路是：将当前的access.log复制一份重命名为新的日志文件，之后清空老的日志文件。

视流量情况（流量越大日志文件积累的越快），按天、小时、分钟来拆分。可以把access.log按天拆分到某个文件夹中。

log_by_day/2021-12-19.log
log_by_day/2021-12-20.log
log_by_day/2021-12-21.log

但上面的复制 -> 清空操作肯定是要自动处理的，这里就需要启动定时任务，在每天固定的时间（我这里是在每天凌晨 00:00）来处理。

定时任务

其实定时任务不仅在日志拆分的时候会用到，在后面的日志分析和日志清除都会用到，这里先简单介绍一下，最终会整合拆分、分析和清除。

linux中内置的cron进程就是来处理定时任务的。在node中我们一般会用node-schedule或cron来处理定时任务。

这里使用的是cron：

/**
    cron 定时规则 https://www.npmjs.com/package/cron
    *    *    *    *    *    *
    ┬    ┬    ┬    ┬    ┬    ┬
    │    │    │    │    │    │
    │    │    │    │    │    └ day of week (0 - 6) (Sun-Sat)
    │    │    │    │    └───── month (1 - 12)
    │    │    │    └────────── day of month (1 - 31)
    │    │    └─────────────── hour (0 - 23)
    │    └──────────────────── minute (0 - 59)
    └───────────────────────── second (0 - 59)
 */

具体使用方式就不展开说明了。

编码

有了上面这些储备，下面我就来写一下这块代码，首先梳理下逻辑：

1️⃣ 读取源文件 access.log

2️⃣ 创建拆分后的文件夹（不存在时需自动创建）

3️⃣ 创建日志文件（天维度，不存在时需自动创建）

4️⃣ 拷贝源日志至新文件

5️⃣ 清空 access.log

/**
 * 拆分日志文件
 *
 * @param {*} accessLogPath
 */
function splitLogFile(accessLogPath) {
  const accessLogFile = path.join(accessLogPath, "access.log");

  const distFolder = path.join(accessLogPath, DIST_FOLDER_NAME);
  fse.ensureDirSync(distFolder);

  const distFile = path.join(distFolder, genYesterdayLogFileName());
  fse.ensureFileSync(distFile);
  fse.outputFileSync(distFile, ""); // 防止重复，先清空

  fse.copySync(accessLogFile, distFile);

  fse.outputFileSync(accessLogFile, "");
}

日志分析

日志分析就是读取上一步拆分好的文件，然后按照一定规则去处理、落库。这里有一个很重要的点要提一下：node在处理大文件或者未知内存文件大小的时候千万不要使用readFile，会突破 V8 内存限制。正是考虑到这种情况，所以这里读取日志文件的方式应该是：createReadStream创建一个可读流交给 readline 逐行读取处理

readline

readline 模块提供了用于从可读流每次一行地读取数据的接口。 可以使用以下方式访问它：

const readline = require("readline");

readline 的使用也非常简单：创建一个接口实例，传入对应的参数：

const readStream = fs.createReadStream(logFile);
const rl = readline.createInterface({
  input: readStream,
});

然后监听对应事件即可：

rl.on("line", (line) => {
  if (!line) return;

  // 获取 url query
  const query = getQueryFromLogLine(line);
  if (_.isEmpty(query)) return;

  // 累加逻辑
  // ...
});
rl.on("close", () => {
  // 逐行读取结束，存入数据库
  const result = eventData.getResult();
  resolve(result);
});

这里用到了line和close事件：

• line事件：每当 input 流接收到行尾输入（\n、\r 或 \r\n）时，则会触发 'line' 事件

• close事件：一般在传输结束时会触发该事件

逐行分析日志结果

了解了readline 的使用，下面让我们来逐行对日志结果进行分析吧。

首先来看下access.log中日志的格式：

我们取其中一行来分析：

127.0.0.1 - - [19/Feb/2021:15:22:06 +0800] "GET /event.png?env=h5&event=pv&key=24&value=2 HTTP/1.1" 200 5233 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36" "-"

我们要拿到的就是url的query部分，也就是我们在h5中自定义的数据。

通过正则匹配即可：

const reg = /GET\s\/event.png\?(.+?)\s/;
const matchResult = line.match(reg);
console.log("matchResult", matchResult);

const queryStr = matchResult[1];
console.log("queryStr", queryStr);

打印结果为：

queryStr可通过node中的querystring.parse()来处理：

const query = querystring.parse(queryStr);



console.log('query', query)

{

  env: 'h5',

  event: 'pv',

  key: '24',

  value: '2'

}

剩下的就是对数据做累加处理了。

但如何去做累加，我们要想一下，最开始也说了是要去做分渠道统计，那么最终的结果应该可以清晰的看到两个数据：

• 所有渠道的数据

• 每个渠道单独的数据

只有这样的数据对于运营才是有价值的，数据的好坏也直接决定了后面在每个渠道投放的力度。

这里我参考了 Google Analytics中的多渠道漏斗的概念，由上到下分维度记录每个维度的数据，这样就可以清晰的知道每个渠道的情况了。

具体实现也不麻烦，我们先来看下刚刚从一条链接中得到的有用数据：

{
  env: 'h5',
  event: 'pv',
  key: '24',
  value: '2'
}

这里的env代表环境，这里统计的都是来源于h5页面，所以env为h5，但是为了扩展，所以设置了这个字段。

event表示事件名称，这里主要是统计访问量，所以为pv。

key是作品 id。

value是渠道 code，目前主要有：1-微信、2-小红书、3-抖音。

再来看下最终统计得到的结果吧：

{
  date: '2021-12-21',
  key: 'h5',
  value: { num: 1276}
}
{
  date: '2021-12-21',
  key: 'h5.pv',
  value: { num: 1000}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12',
  value: { num: 200}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12.1',
  value: { num: 56}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12.2',
  value: { num: 84}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12.3',
  value: { num: 60}
}

这是截取了2021-12-21当天的数据，我给大家分析一波：

1️⃣ h5：当天 h5 页面的自定义事件上报总数为 1276

2️⃣ h5.pv：其中 所有 pv（也就是 h5.pv）为 1000

3️⃣ h5.pv.12：作品 id 为 12 的 pv 一共有 200

4️⃣ h5.pv.12.1：作品 id 为 12 的在微信渠道的 pv 为 56

5️⃣ h5.pv.12.2：作品 id 为 12 的在小红书渠道的 pv 为 84

6️⃣ h5.pv.12.2：作品 id 为 12 的在抖音渠道的 pv 为 60

这样就能清楚的得到某一天某个作品在某条渠道的访问情况了，后续再以这些数据为支撑做成可视化报表，效果就一目了然了。

统计结果入库

目前这部分数据是放在了mongoDB中，关于node中使用mongoDB就不展开说了，不熟悉的可以参考我另外一篇文章Koa2+MongoDB+JWT 实战--Restful API 最佳实践

这里贴下model吧：

/**
 * @description event 数据模型
 */
const mongoose = require("../db/mongoose");

const schema = mongoose.Schema(
  {
    date: Date,
    key: String,
    value: {
      num: Number,
    },
  },
  {
    timestamps: true,
  }
);

const EventModel = mongoose.model("event_analytics_data", schema);

module.exports = EventModel;

日志删除

随着页面的持续访问，日志文件会快速增加，超过一定时间的日志文件存在的价值也不是很大，所以我们要定期清除日志文件。

这个其实比较简单，遍历文件，因为文件名都是以日期命名的(格式：2021-12-14.log)，所以只要判断时间间隔大于 90 天就删除日志文件。

贴一下核心实现：

// 读取日志文件
const fileNames = fse.readdirSync(distFolder);
fileNames.forEach((fileName) => {
  try {
    // fileName 格式 '2021-09-14.log'
    const dateStr = fileName.split(".")[0];
    const d = new Date(dateStr);
    const t = Date.now() - d.getTime();
    if (t / 1000 / 60 / 60 / 24 > 90) {
      // 时间间隔，大于 90 天，则删除日志文件
      const filePath = path.join(distFolder, fileName);
      fse.removeSync(filePath);
    }
  } catch (error) {
    console.error(`日志文件格式错误 ${fileName}`, error);
  }
});

定时任务整合

到这里，日志的拆分、分析和清除都说完了，现在要用cron来对他们做整合了。

首先来创建定时任务：

function schedule(cronTime, onTick) {
  if (!cronTime) return;
  if (typeof onTick !== "function") return;

  // 创建定时任务
  const c = new CronJob(
    cronTime,
    onTick,
    null, // onComplete 何时停止任务
    true, // 初始化之后立刻执行
    "Asia/Shanghai" // 时区
  );

  // 进程结束时，停止定时任务
  process.on("exit", () => c.stop());
}

然后每一阶段都在不同的时间阶段去处理（定时拆分 -> 定时分析 -> 定时删除）

定时拆分

function splitLogFileTiming() {
  const cronTime = "0 0 0 * * *"; // 每天的 00:00:00
  schedule(cronTime, () => splitLogFile(accessLogPath));
  console.log("定时拆分日志文件", cronTime);
}

定时分析并入库

function analysisLogsTiming() {
  const cronTime = "0 0 3 * * *"; // 每天的 3:00:00 ，此时凌晨，访问量较少，服务器资源处于闲置状态
  schedule(cronTime, () => analysisLogsAndWriteDB(accessLogPath));
  console.log("定时分析日志并入库", cronTime);
}

定时删除

function rmLogsTiming() {
  const cronTime = "0 0 4 * * *"; // 每天的 4:00:00 ，此时凌晨，访问量较少，服务器资源处于闲置状态
  schedule(cronTime, () => rmLogs(accessLogPath));
  console.log("定时删除过期日志文件", cronTime);
}

然后在应用入口按序调用即可：

// 定时拆分日志文件
splitLogFileTiming();
// 定时分析日志并入库
analysisLogsTiming();
// 定时删除过期日志文件
rmLogsTiming();

总结

ok，到这里，一个简易的统计服务就完成了。

作者：前端森林
来源：https://segmentfault.com/a/1190000041184489

真正的大师永远怀着一颗学徒的心

引言

对于一个软件平台来说，软件平台代码的好坏直接影响平台整体的质量与稳定性。同时也会影响着写代码同学的创作激情。想象一下如果你从git上面clone下来的的工程代码乱七八糟，代码晦涩难懂，难以快速入手，有种想推到重写的冲动，那么程序猿在这个工程中写好代码的初始热情都没了。相反，如果clone下的代码结构清晰，代码优雅易懂，那么你在写代码的时候都不好意思写烂代码。这其中的差别相信工作过的同学都深有体会，那么我们看了那么多代码之后，到底什么样的代码才是好代码呢？它们有没有一些共同的特征或者原则？本文通过阐述优雅代码的设计原则来和大家聊聊怎么写好代码。

代码设计原则

好代码是设计出来的，也是重构出来的，更是不断迭代出来的。在我们接到需求，经过概要设计过后就要着手进行编码了。但是在实际编码之前，我们还需要进行领域分层设计以及代码结构设计。那么怎么样才能设计出来比较优雅的代码结构呢？有一些大神们总结出来的优雅代码的设计原则，我们分别来看下。

SRP

所谓SRP（Single Responsibility Principle）原则就是职责单一原则，从字面意思上面好像很好理解，一看就知道什么意思。但是看的会不一定就代表我们就会用，有的时候我们以为我们自己会了，但是在实际应用的时候又会遇到这样或者那样的问题。原因就是实际我们没有把问题想透，没有进行深度思考，知识还只是知识，并没有转化为我们的能力。就比如这里所说的职责单一原则指的是谁的单一职责，是类还是模块还是域呢？域可能包含多个模块，模块也可以包含多个类，这些都是问题。

为了方便进行说明，这里以类来进行职责单一设计原则的说明。对于一个类来说，如果它只负责完成一个职责或者功能，那么我们可以说这个类时符合单一职责原则。请大家回想一下，其实我们在实际的编码过程中，已经有意无意的在使用单一职责设计原则了。因为实际它是符合我们人思考问题的方式的。为什么这么说呢？想想我们在整理衣柜的时候，为了方便拿衣服我们会把夏天的衣服放在一个柜子中，冬天的衣服放在一个柜子。这样季节变化的时候，我们只要到对应的柜子直接拿衣服就可以了。否则如果冬天和夏天的衣服都放在一个柜子中，我们找衣服的时候可就费劲了。放到软件代码设计中，我们也需要采用这样的分类思维。在进行类设计的时候，要设计粒度小、功能单一的类，而不是大而全的类。

举个栗子，在学生管理系统中，如果一个类中既有学生信息的操作比如创建或者删除动作，又有关于课程的创建以及修改动作，那么我们可以认为这个类时不满足单一职责的设计原则的，因为它将两个不同业务域的业务混杂在了一起，所以我们需要进行拆分，将这个大而全的类拆分为学生以及课程两个业务域，这样粒度更细，更加内聚。

笔者根据自身的经验，总结了需要考虑进行单一职责拆分的几个场，希望对大家判断是否需要进行拆分有个简单的判断的标准： 1、不同的业务域需要进行拆分，就像上面的例子，另外如果与其他类的依赖过多，也需要考虑是不是应该进行拆分； 2、如果我们在类中编写代码的时候发现私有方法具有一定的通用性，比如判断ip是不是合法，解析xml等，那我们可以考虑将这些方法抽出来形成公共的工具类，这样其他类也可以方便的进行使用。 另外单一职责的设计思想不止在代码设计中使用，我们在进行微服务拆分的时候也会一定程度的遵循这个原则。

OCP

OCP（Open Closed Principle）即对修改关闭，对扩展开放原则，个人觉得这是设计原则中最难的原则。不仅理解起来有一定的门槛，在实际编码过程中也是不容易做到的。 首先我们得先搞清楚这里的所说的修改以及扩展的区别在什么地方，说实话一开始看到这个原则的时候，我总觉得修改和开放说的不是一个意思嘛？想来想去都觉得有点迷糊。后来在不断的项目实践中，对这个设计原则的理解逐渐加深了。

设计原则中所说的修改指的是对原有代码的修改，而扩展指的是在原有代码基础上的能力的扩展，并不修改原先已有的代码。这是修改与扩展的最大的区别，一个需要修改原来的代码逻辑，另一个不修改。因此才叫对修改关闭但是对扩展开放。弄清楚修改和扩展的区别之后，我们再想一想为什么要对修改关闭，而要对扩展开放呢？ 我们都知道软件平台都是不断进行更新迭代的，因此我们需要不断在原先的代码中进行开发。那么就会涉及到一个问题如果我们的代码设计的不好，扩展性不强，那么每次进行功能迭代的时候都会修改原先已有的代码，有修改就有可能引入bug，造成系统平台的不稳定。因此我们为了平台的稳定性，需要对修改关闭。但是我们要添加新的功能怎么办呢？那就是通过扩展的方式来进行，因此需要实现对扩展开放。

这里我们以一个例子来进行说明，否则可能还是有点抽象。在一个监控平台中，我们需要对服务所占用CPU、内存等运行信息进行监控，第一版代码如下。

public class Alarm {
    private AlarmRule alarmRule;
    private AlarmNotify alarmNotify;
    
    public Alarm(AlarmRule alarmRule, AlarmNotify alarmNotify) {
        this.alarmRule = alarmRule;
        this.alarmNotify = alarmNotify;
    }
    
    public void checkServiceStatus(String serviecName, int cpu, int memory) {
        if(cpu > alarmRule.getRule(ServiceConstant.Status).getCpuThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        }
        
         if(memory > alarmRule.getRule(ServiceConstant.Status).getMemoryThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        } 
    
    }

}

代码逻辑很简单，就是根据对应的告警规则中的阈值判断是否达到触发告警通知的条件。如果此时来了个需求，需要增加判断的条件，就是根据服务对应的状态，判断需不需要进行告警通知。我们来先看下比较low的修改方法。我们在checkServiceStatus方法中增加了服务状态的参数，同事在方法中增加了判断状态的逻辑。

public class Alarm {
    private AlarmRule alarmRule;
    private AlarmNotify alarmNotify;
    
    public Alarm(AlarmRule alarmRule, AlarmNotify alarmNotify) {
        this.alarmRule = alarmRule;
        this.alarmNotify = alarmNotify;
    }
    
    public void checkServiceStatus(String serviecName, int cpu, int memory， int status) {
        if(cpu > alarmRule.getRule(ServiceConstant.Status).getCpuThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        }
        
         if(memory > alarmRule.getRule(ServiceConstant.Status).getMemoryThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        } 
        
         if(status == alarmRule.getRule(ServiceConstant.Status).getStatusThreshold) {
            alarmNotify.notify(serviecName +  alarmRule.getRule(ServiceConstant.Status).getDescription)
        } 
    
    }

}