Problem
The n-queens puzzle is the problem of placing n
queens on an n x n
chessboard such that no two queens attack each other.
Given an integer n
, return the number of distinct solutions to the n-queens puzzle.
You are given an array of positive integers nums
and want to erase a subarray containing unique elements. The score you get by erasing the subarray is equal to the sum of its elements.
Return the maximum score you can get by erasing exactly one subarray.
An array b
is called to be a subarray of a
if it forms a contiguous subsequence of a
, that is, if it is equal to a[l],a[l+1],...,a[r]
for some (l,r)
.
A decimal number is called deci-binary if each of its digits is either 0
or 1
without any leading zeros. For example, 101
and 1100
are deci-binary, while 112
and 3001
are not.
Given a string n
that represents a positive decimal integer, return the minimum number of positive deci-binary numbers needed so that they sum up to n
.
Evaluate the value of an arithmetic expression in Reverse Polish Notation.
Valid operators are +
, -
, *
, and /
. Each operand may be an integer or another expression.
Note that division between two integers should truncate toward zero.
It is guaranteed that the given RPN expression is always valid. That means the expression would always evaluate to a result, and there will not be any division by zero operation.
微服务兴起后,最近有一个词非常热,叫Service Mesh。很多大厂都极力在推广,这个东西到底是什么呢?在这篇博客我将和大家分享一下有关Service Mesh的知识。
什么是Service Mesh?中文叫服务网格,它是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中,Service Mesh通常以轻量级网络代理阵列的形式实现,这些代理与应用程序代码部署在一起,对应用程序来说不需要感知到代理的存在。
在了解Service Mesh的工作原理前,首先要知道它诞生的原因,它是解决了软件工程实践中的什么问题。在微服务架构流行并普及后,许多业务都遇到了同一个问题:单个微服务的复杂度大幅度降低,但是系统的整体复杂度并没有下降,反而增加了服务之间连接、管理、监控的复杂度。微服务之间都通过RPC的方式获取数据,每个微服务除了包含本身的业务逻辑外,还需要处理RPC调用的通讯相关问题,包括限流、权限等。这使得开发者无法把精力都集中到业务逻辑的开发中,当业务场景变得复杂后,这对开发者来说是一个更加大的挑战。
此时,一种通用的框架应运而生,它的基本思路是,把每个微服务中的通讯部分抽流出来统一交给框架处理,而开发者只需要专注于业务开发。这样做的好处是,一是开发者可以专注在业务上,而不需要开发过程中过多地关注微服务之间的通讯问题;二是以通用框架的方式去管理微服务可以更加方便运维,包括流量控制、权限控制等。
这里我用一个简单的例子去说明Service Mesh的作用。在Service Mesh之前,如果我要开发一个微服务A,我需要考虑它的业务逻辑,同时,它对外暴露的接口我也需要做频控、权限控制;如果我再开发一个微服务B,我需要做同样的事情。这里比较理想的做法可能是把频控、权限控制相关的代码都封装成一个通用库,每个微服务都去使用。但其实这种方法也有缺陷,当需要升级时,几乎每个微服务都需要升级一遍。更大的问题是,如果我想禁止掉A对B服务调用某个接口,会很不方便,甚至需要改动的代码来完成。
当有了Service Mesh后,这一切变得不同。首先无论是开发A还是B服务,我不需要关系通讯相关的问题,我只需要在Service Mesh提供的平台上配置。同时,当我需要禁止掉某个接口时,直接在运维平台上操作即可,而不需要涉及到代码的改动,这个生效时间是非常短的。
这一部分来看看Service Mesh的一些细节及原理。首先来看一张架构图:
上图中,绿色部分指的是微服务本身,承载着业务逻辑;蓝色部分指的是随着服务部署的服务网格,是作为sidecar运行在同一个容器中;蓝色的线条表示微服务之间的通讯。整个图片看上去蓝色的方块和线条编织起了一个通讯的网络框架,这就是服务网格的意思,所有的服务都在这个网格之上。
所以服务网格也可以理解为是若干个sidecar服务构成的网络,其中现在业界有很多著名的框架,如Istio等。我们就来看看他们具体是怎么工作的:
简单来说Service Mesh为微服务提供了一个监控的框架,能够让业务开发者专注在业务逻辑的开发,而不需要考虑微服务之间的通讯问题。同时也通过框架的形式,提供高可用的通讯框架,以及汇总更多的监控信息用于维护。总的来说Service Mesh会是未来的趋势,许多大厂现在也在极力推Service Mesh。
The n-queens puzzle is the problem of placing n
queens on an n x n
chessboard such that no two queens attack each other.
Given an integer n
, return all distinct solutions to the n-queens puzzle. You may return the answer in any order.
Each solution contains a distinct board configuration of the n-queens’ placement, where 'Q'
and '.'
both indicate a queen and an empty space, respectively.
Golang给开发者提供了一个很成熟的单元测试框架,我们可以直接使用go test
来执行测试。但是在单元测试中还有需要细节要考虑的,比如哪些文件会运行?测试的范围是什么?这些测试是串行运行还是并行运行等,这些都是我们实际应用时要考虑的问题。
我们在运行go test
命令后,哪些测试文件会被执行,他的范围又是什么?
首先在某个文件夹下执行了go test
命令后,这个命令会在当前的package中寻找符合*_test.go
的文件,并在这些文件中找到TestXxx(*testing.T){}
、BenchmarkXxx(b *testing.B) {}
、ExampleXxx() {}
这些函数执行测试用例。
如果想要执行当前package下所有的测试用例,可以使用命令go test ./...
,这样就会搜索当前目录及子目录下所有符合要求的测试文件。
在测试过程中测试用例的执行串行还是并行很重要吗?当然,这直接影响着测试的结果。试想一下如果测试的时候需要连接到测试的本地数据库,A用例需要创建一条记录,而B用例则需要删除一条记录,如果是并行的话就会有意想不到的效果。这会导致每次测试的结果可能都不同,无法有效地测试代码的正确性。
默认情况下,在不同的package之间的测试是并行的,在package内部是串行的。但是如果在package内部需要串行执行的话,就需要显式执行t.Parallel()
或者在运行命令是带上参数go test -parallel 1 -p 1
。第一个参数-parallel
设定的是并行测试函数的数目,对应的是package内部的测试,默认值是GOMAXPROCS
;第二个参数-p
设定的是并行测试的test binary数目,对应的是package之间的测试,默认值是CPU的核数。
这里简单分享一些有关Go单元测试的小知识,后续遇到了相关的问题会继续在这里分享。