ORA-12638: 身份证明检索失败的解决方法

在用SQL Developer创建DBLINK时,测试过程出现 ORA-12638: 身份证明检索失败,TNS配置没有问题。

解决方案:

E:\Tools\oracle_database_12c\network\admin

此目录下找到sqlnet.ora文件,如果存在SQLNET.AUTHENTICATION_SERVICES= (NTS)设置,则修改为:SQLNET.AUTHENTICATION_SERVICES= (NONE),如果不存在,则直接添加SQLNET.AUTHENTICATION_SERVICES= (NONE),问题得以解决。

函数sin(r)/r的图形输出样例

package main
//根据一个三维曲面函数计算并生成svg
import (
	"fmt"
	"math"
	"net/http"
)

const (
	width, height = 600, 320 //以像素表示的画布大小
	cells         = 100 //网格单元的个数
	xyrange       = 30.0//坐标轴的范围 (-xyrange,xyrange)
	xyscale       = width / 2 / xyrange //x 或 y轴上每个单位长度的像素
	zscale        = height * 0.4 //z轴上每个单位长度的像素
	angle         = math.Pi / 6//x、y轴的角度 (=30°)
)

var sin30, cos30 = math.Sin(angle), math.Cos(angle)

func main() {
	http.HandleFunc("/", drawSVG)
	http.ListenAndServe("localhost:8080", nil)
}

func drawSVG(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-type", "image/svg+xml")
	_, _ = fmt.Fprintf(w, "<svg xmlns='http://www.w3.org/2000/svg' "+
		"style='stroke:grey;fill:white;stroke-width:0.7' width='%d' height='%d'>\n",
		width, height)
	for i := 0; i < cells; i++ {
		for j := 0; j < cells; j++ {
			ax, ay := corner(i+1, j)
			bx, by := corner(i, j)
			cx, cy := corner(i, j+1)
			dx, dy := corner(i+1, j+1)
			_, _ = fmt.Fprintf(w, "<polygon points='%g,%g,%g,%g,%g,%g,%g,%g' />\n", ax, ay, bx, by, cx, cy, dx, dy)
		}
	}
	_, _ = fmt.Fprintf(w, "</svg>")
}

func corner(i, j int) (float64, float64) {
	//求出网格单元 (i,j)的顶点坐标(x,y)
	x := xyrange * (float64(i)/cells - 0.5)
	y := xyrange * (float64(j)/cells - 0.5)
	//计算曲面高度 z
	z := f(x, y)
	//将(x,y,z)等角投射到二维svg绘图平面上,坐标(sx,sy)
	sx := width/2 + (x-y)*cos30*xyscale
	sy := height/2 + (x+y)*sin30*xyscale - z*zscale
	return sx, sy
}

func f(x, y float64) float64 {
	r := math.Hypot(x, y) //到(0,0)的距离
	return math.Sin(r)/r
}

访问浏览器 http://localhost:8080 ,浏览器会展示如下图形

3d表达sin(r)/r

比较特殊的输出格式符

%q 输出被双引号扩起来的字符串,并且会将字符串中的双引号进行转义。

fmt.Printf(“%q”,”abc\””)

输出 “abc\””,而不是abc”

%+v 输出结构体格式,并且带着字段名。

fmt.Printf(“%+v”,Coordinate{Lon:1,Lat:1})

输出{Lon:1,Lat:1}

%#v 这输出go语言的语法表示,如输出Coordinate{Lon:1,Lat:1}

%T 输出变量的类型,如输出Coordinate。

%[1]d 表示输出第一个参数,go语言支持指定输出顺序。

fmt.Printf(“%d , %[1]d”,123)

另外:

\r 是个很酷的格式符,会从当前行头开始显示,比如循环输出计数时可以用到。

越过山丘-李雅

https://win-web-ri01-sycdn.kuwo.cn/84fcb63073ef75dbd133cd5eb59a6f17/5d6931a1/resource/n2/89/82/924825770.mp3 可下载。

大鱼-周深&郭沁

https://win-web-nf01-sycdn.kuwo.cn/89d95ec19578a97741ad9f601df0a737/5d69383e/resource/n2/0/45/2382586584.mp3 可下载。

她来听我的演唱会-希林娜依·高

https://win-web-nf01-sycdn.kuwo.cn/af07df01ec2ef973db252b07d08b1140/5d694231/resource/n3/5/13/2962999144.mp3

男孩-梁博&希林娜依·高

https://win-web-nf01-sycdn.kuwo.cn/d141f19ae16f6d36d8f5ab1d075dd3b2/5d694282/resource/n1/53/54/3242993900.mp3

紫(live)-郭沁

https://win-web-nf01-sycdn.kuwo.cn/092d9567850bed9be082ba49d8daf8c7/5d694607/resource/n2/1/15/913505490.mp3

判断某点是否在圆形、三角形内

go语言实现的函数

计算两点距离,圆心与某点距离小于等于半径,计算某点和三角形三个点组成的三个小三角形的面积之和是否等于该三角形的面积。

package twod

import (
	"fmt"
	"math"
)

type Coordinate struct {
	Lat float64
	Lon float64
}

//compute the distance between two coordinates
func ComputeDistance(a Coordinate, b Coordinate) float64 {
	return math.Sqrt(math.Pow(b.Lon-a.Lon, 2) + math.Pow(b.Lat-a.Lat, 2))
}

func InsideCircle(center Coordinate, radius float64, p Coordinate) bool {
	return ComputeDistance(center, p) <= radius
}

//compute the angel of ∠BAC
func ComputeAngle(a Coordinate, b Coordinate,c Coordinate) float64{
	lenAC :=ComputeDistance(a,c)
	lenAB :=ComputeDistance(a,b)
	lenBC :=ComputeDistance(b,c)
	molecule :=math.Pow(lenAB,2) + math.Pow(lenAC,2) - math.Pow(lenBC,2)
	denominator := 2*lenAB*lenAC
	return math.Acos(molecule/denominator)*180/math.Pi
}

//compute the area of a triangle
func ComputeArea(a Coordinate, b Coordinate,c Coordinate) float64{
	lenCA :=ComputeDistance(c,a)
	lenCB :=ComputeDistance(c,b)
	lenAB :=ComputeDistance(b,a)

	if lenCA+lenCB > lenAB && lenCB+lenAB > lenCA &&lenAB+lenCA < lenCB {
		panic("not a triangle")
	}

	perimeter :=lenCA+lenCB+lenAB
	return math.Sqrt(perimeter/2*(perimeter/2-lenCA)*(perimeter/2-lenCB)*(perimeter/2-lenAB))
}

func InsideTriangle(a Coordinate, b Coordinate,c Coordinate, p Coordinate) bool {
	areaABP :=ComputeArea(a,b,p)
	areaBCP:=ComputeArea(b,c,p)
	areaCAP :=ComputeArea(c,a,p)

	areaABC :=ComputeArea(a,b,c)
	return fmt.Sprintf("%.3f", areaABP+areaBCP+areaCAP) == fmt.Sprintf("%.3f", areaABC)
}

调用示例:

length := twod.ComputeDistance(
		twod.Coordinate{Lon: 0.3,Lat: 0.3},
		twod.Coordinate{Lon: 1,Lat: 1})
	log.Printf("%.2f", length)

	log.Println(twod.InsideCircle(twod.Coordinate{Lon: 0, Lat: 0}, 5,
		twod.Coordinate{Lon: 0, Lat: 4.8}))

	inside := twod.InsideTriangle(
		twod.Coordinate{Lon: 0, Lat: 0},
		twod.Coordinate{Lon: 50, Lat: 50},
		twod.Coordinate{Lon: 100, Lat: 0},
		twod.Coordinate{Lon: 2, Lat: 2})
	log.Println(inside)

	angel := twod.ComputeAngle(twod.Coordinate{Lon: 0, Lat: 0},
		twod.Coordinate{Lon: 1, Lat: 0},
		twod.Coordinate{Lon: 1, Lat: 3})
	log.Printf("%.2f", angel)

利息计算器

每年固定存款25000,存20年;本息合计79万。

然后将本息总金额继续存20年,不再追加本金,只赚利息。

四十年后本息合计170万。

中台是个什么鬼

从去年开始,好像就有一只无形的手一直将我与“微服务”、“平台化”、“中台化”撮合在一起,给我带来了很多的困扰和思考与收获。

故事的开始源于去年的技术雷达峰会,我在会上做了一场关于平台崛起的主题分享(《The Rise of Platform》),这场分享主要是从技术的层面从Global的视角介绍了平台化的兴起,以及分享从基础设施到人工智能等各个领域不断涌现的各类平台,以及平台化对于软件开发人员及企业的影响。

(2017技术雷达峰会)

记得当时在做演讲彩排的时候,有同事就提到过,在中国提“数字化平台战略”可能大家会觉得比较抽象比较远大空,如果你提“中台”大家会更熟悉一些。

而这也是我第一次听到“中台”这个词,原来除了我们熟悉的“前台”和“后台”外,居然还有个“中台”这样一个神奇的存在。

那…… 中台到底是什么?会不会又是另一个Buzzword呢?这个从名字上看像是从前台与后台中间硬挤出来的新断层,它与前台和后台的区别和界限到底在哪儿?什么应该放到中台,什么又应该放到前台或是后台?它的出现到底是为了解决什么问题呢?

从那时开始,一个接一个的问题就不断的涌出并萦绕在我的脑子里。直到一年多后的今天,随着参与的几个平台化、企业中台相关的项目已经顺利地步上了正轨,终于可以坐下来回顾一下这一年的实践与思考,再次试图回答这些问题,并梳理成文,与大家交流探讨。

中台迷思

到处都在喊中台,到处都是中台,中台这个词在我看来已经被滥用了。

  • 在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。
  • 在有些人眼里:中台就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地,人们都叫它“业务中台”。
  • 在有些人眼里:中台应该是组织的事情,在释放潜能:平台型组织的进化路线图 (豆瓣)中就提出了平台型组织和组织中台的概念,这类组织中台在企业中主要起到投资评估与投后管理的作用,类似于企业内部资源调度中心和内部创新孵化组织,人们叫它“组织中台”

看完本篇你就会理解,上边的这几类“中台”划分还是靠谱的,更多我看到的情况是大家为了响应企业的“中台战略”,干脆直接将自己系统的“后端”或是“后台”改个名,就叫“中台”。

中台到底是什么?它对于企业的意义到底是什么?当我们谈中台时我们到底在谈些什么?

想要寻找到答案,仅仅沉寂在各自“中台”之中,如同管中窥豹,身入迷阵,是很难想清楚的。不如换个角度,从各类的“中台迷阵”中跳脱出来,尝试以更高的视角,从企业均衡可持续发展的角度,来思考中台的价值,来试图反推它存在的价值。

所以,为了搞明白中台存在的价值,我们需要回答以下两个问题:

  1. 企业为什么要平台化?
  2. 企业为什么要建中台?

第一个问题:企业为什么要平台化?

先给答案,其实很简单:

因为在当今互联网时代,用户才是商业战场的中心,为了快速响应用户的需求,借助平台化的力量可以事半功倍。

不断快速响应、探索、挖掘、引领用户的需求,才是企业得以生存和持续发展的关键因素。

那些真正尊重用户,甚至不惜调整自己颠覆自己来响应用户的企业将在这场以用户为中心的商业战争中得以生存和发展;反之,那些在过去的成就上故步自封,存在侥幸心理希望用户会像之前一样继续追随自己的企业则会被用户淘汰。

很残酷,但这就是这个时代最基本的企业生存法则

数字化企业

平台化之所以重要,就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最最最核心的能力:用户响应力。这种能力可以帮助企业在商战上先发制人,始终抢得先机。

可以说,在互联网时代,商业的斗争就是对于用户响应力的比拼。

又有点远大空是不是,我们来看个经典的例子:

1.说起中台,最先想到的应该就属是阿里的“大中台,小前台”战略。阿里通过多年不懈的努力,在业务的不断催化滋养下,将自己的技术和业务能力沉淀出一套综合能力平台,具备了对于前台业务变化及创新的快速响应能力。

(阿里中台)

2.海尔也早在几年前就已经开始推进平台化组织的转型,提出了“平台经营体支撑一线经营体”的战略规划和转型目标。构建了“人单合一”、“用户付薪” 的创客文化,真正将平台化提高到了组织的维度。

(海尔组织中台)

3.华为在几年前就提出了“大平台炮火支撑精兵作战”的企业战略,“让听得到炮声的人能呼唤到炮火” 这句话形象的诠释了大平台支撑下小前台的作战策略。这种极度灵活又威力巨大的战法,使之可以迅速响应瞬息万变的战场,一旦锁定目标,通过大平台的炮火群,迅速精准对于战场进行强大的火力支援。

(大平台炮火支撑精兵作战)

可是,在互联网热火朝天,第四次工业革命的曙光即将到来的今日,企业能否真正做到“以用户为中心”,并不断提升自己的用户响应力来追随甚至引领用户的脚步,持续规模化创新,终将决定企业能否在这样充满挑战和机遇的市场上笑到最后,在商业上长久保持创新活力与竞争力。

(数字化平台战略)

而平台化恰好可以助力企业更快更好的做到这些,所以这回答了第一个问题,企业需要平台化。

第二个问题:企业为什么要建中台?

好,想明白了第一个问题,为什么需要平台化。但是平台化并不是一个新概念,很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起?对于企业来讲,传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?

好,这就引出了我们的第二个问题:企业为什么要建中台?

来,先定义一下前台与后台

因为平台这个词过于宽泛了,为了能让大家理解我在说什么,我先定义一下本篇文章上下文下我所说的前台和后台各指什么:

  • 前台:由各类前台系统组成的前端平台。每个前台系统就是一个用户触点,即企业的最终用户直接使用或交互的系统,是企业与最终用户的交点。例如用户直接使用的网站,手机App,微信公众号等都属于前台范畴。
  • 后台:由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源(数据+计算),例如财务系统,产品系统,客户管理系统,仓库物流管理系统等,这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源,也属于后台的一部分。

后台并不为前台而生

定义了前台和后台,对于第二个问题(企业为什么要建中台),同样先给出我的答案:

因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求,后台更多解决的是企业管理效率问题,而中台要解决的才是前台的创新问题

大多数企业已有的后台,要么前台根本就用不了,要么不好用,要么变更速度跟不上前台的节奏。

我们看到的很多企业的后台系统,在创建之初的目标,并不是主要服务于前台系统创新,而更多的是为了实现后端资源的电子化管理,解决企业管理的效率问题。这类系统要不就是当年花大价钱外购,需要每年支付大量的服务费,并且版本老旧,定制化困难;要不就是花大价钱自建,年久失修,一身的补丁,同样变更困难,也是企业所谓的“遗留系统”的重灾区。

总结下来就两个字“慢”和“贵”,对业务的响应慢,动不动改个小功能就还要花一大笔钱。

有人会说了,你不能拿遗留系统说事儿啊,我们可以新建后台系统啊,整个2.0问题不就解决了。

但就算是新建的后台系统,因为其管理的是企业的关键核心数据,考虑到企业安全、审计、合规、法律等限制。导致其同样往往无法被前台系统直接使用,或是受到各类限制无法快速变化,以支持前台快速的创新需求。

此时的前台和后台就像是两个不同转速的尺轮,前台由于要快速响应前端用户的需求,讲究的是快速创新迭代,所以要求转速越快越好;而后台由于针对的是相对稳定的后端资源,而且往系统陈旧复杂,甚至还受到法律法规审计等相关合规约束,所以往往是稳定至上,越稳定越好, 转速也自然是越慢越好。

所以,随着企业务的不断发展,这种“前台+后台”的尺轮速率“匹配失衡”的问题就逐步显现出来。

随着企业业务的发展壮大,因为后台修改的成本和风险较大,所以驱使我们会尽量选择保持后台系统的稳定性,但还要响应用户持续不断的需求,自然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中,引入重复的同时还会致使前台系统不断膨胀,变得臃肿,形成了一个个⼤泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“用户响应快”,用户满意度降低,企业竞争力也随之不断下降。

对于这样的问题,Gatner在2016年提出的一份《Pace-Layered Application Strategy》报告中,给出了一种解决方案,即按照“步速”将企业的应用系统划分为三个层次(正好契合前中后台的三个层次),不同的层次采用完全不同的策略。

而Pace-Layered Application Strategy也为“中台”产生的必然性,提供了理论上的支撑。

Pace-Layered Application Strategy

(Gatner: Pace-Layered Application Strategy)

在这份报告中Gatner提出,企业构建的系统从Pace-Layered的角度来看可以划分为三类: SOR(Systems of record ),SOD(Systems of differentiation)和SOI(Systems of innovation)。

处于不同Pace-Layered的系统因为⽬的不同,关注点不同,要求不同,变化的“速率”自然也不同,匹配的也需要采取不同的技术架构,管理流程,治理架构甚至投资策略。

前面章节我们提到的后台系统,例如CRM、ERP、财务系统等,它们大多都处于SOR的Pace-Layered。这些系统的建设之初往往是以规范处理企业底层资源和企业的核心可追溯单据(例如财务单据,订单单据)为主要目的。它们的变更周期往往比较长,而且由于法律律审计等其他限制,导致对于它们的变更需要严谨的申报审批流程和更高级别的测试部署要求,这就导致了它们往往变化频率低,变化成本高,变化风险高,变化周期长。无法满足由用户驱动的快速变化的前台系统要求。

我们又要尽力保持后台(SOR)系统的稳定可靠,又要前台系统(SOI)能够小而美,快速迭代。就出现了上文提到的”齿轮匹配失衡“的问题,感觉鱼与熊掌不可兼得。

正当陷入僵局的时候,天空中飘来一声IT谚语:

软件开发中遇到的所有问题,都可以通过增加一个抽象层得以解决!

为此,一声惊雷滚过,“中台”脚踏七彩祥云,承载着SOD(Systems of differentiation) 的前世寄托,横空出世。

中台才是为前台而生

我们先试着给中台下个定义:

中台是真正为前台而生的平台(可以是技术平台,业务能力甚至是组织机构),它存在的唯一目的就是更好的服务前台规模化创新,进而更好的响应服务引领用户,使企业真正做到自身能力与用户需求的持续对接。

中台就像是在前台与后台之间添加的一组“变速尺轮”,将前台与后台的速率进行匹配,是前台与后台的桥梁。它为前台而生,易于前台使用,将后台资源顺滑流向用户,响应用户。

中台很像Pace-Layered中的SOD,提供了比前台(SOI)更强的稳定性,以及后后台(SOR)更高的灵活性,在稳定与灵活之间寻找到了一种美妙的平衡。

中台作为变速齿轮,链接了用户与企业核心资源,并解决了配速问题

有了“中台”这种新的Pace-Layered断层,我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层,为前台减肥,恢复前台的响应力;又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层,赋予这些业务能力更强的灵活度和更低的变更成本,从而为前台提供更强大的“能力炮火”支援。

所以,企业在平台化的过程中,需要建设自己的中台层(同时包括技术中台,业务中台和组织中台)。

总结

思考并回答了文初提出的两个关于中台价值的核心问题,解决了我对于中台产生的一些困惑,不知道对你有没有启发,让我最后再来总结一下:

  • 以用户为中心的持续规模化创新,是中台建设的核心目标。企业的业务响应能力和规模化创新能力,是互联网时代企业综合竞争力的核心体现。平台化包括中台化只是帮助企业达到这个目标的手段,并不是目标本身。
  • 中台(无论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应力困境, 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的矛盾,提供一个中间层来适配前台与后台的配速问题,沉淀能力,打通并顺滑链接前台需求与后台资源,帮助企业不断提升用户响应力。
  • 所以,中台到底是什么根本不重要,如何想方设法持续提高企业对于用户的响应力才是最重要的。大平台化或是中台化,只是恰巧走在了了这条正确的道道上。