利息计算器

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

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

总结

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

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

IP地址与CIDR

CIDR采用各种长度的”网络前缀”来代替分类地址中的网络号和子网号,其格式为:IP地址 = {<网络前缀>,<主机号>}。为了区分网络前缀,通常采用”斜线记法”(CIDR记法),即IP地址/网络前缀所占比特数。例如:192.168.24.0/22 表示32位的地址中,前22位为网络前缀,后10(32-22=10)位代表主机号。在换算中,192.168.24.0/22 对应的二进制为:

1100 0000(192),1010 1000(168),0001 1000(24),0000 0000(0)

其中红色为主机号,总共有10位。当这10位全为0时,取最小地址192.168.24.0,当这10位全为1时,取最大地址192.168.27.255。但请注意,在实际中,主机号全为0或者全为1的地址一般不使用,作为预留地址另有作用。所以第一个地址为1100 0000,1010 10000,0001 1000,0000 0001,即192.168.24.1 最后一个地址为:1100 0000,1010 10000,0001 1011,1111 1110,即192.168.27.254

因此,本例中将第三段地址数据中最小是00011000(24),最大是00011011(27),第四段地址数据中最小为0000 0001(1),最大为1111 1110(254),以上括号中数据为十进制,其前面为二进制。所以本例中192.168.24.0/22 对应地址段为192.168.24.1-192.168.27.254,共4个网段。

一、 IP地址概念

IP地址是一个32位的二进制数,它由网络ID和主机ID两部份组成,用来在网络中唯一的标识的一台计算机。网络ID用来标识计算机所处的网段;主 机ID用来标识计算机在网段中的位置。IP地址通常用4组3位十进制数表示,中间用“.”分隔。比如,192.168.0.1。

补充(IPv6):前面所讲的32位IP地址称之为IPv4,随着信息技术的发展,IPv4可用IP地址数目已经不能满足人们日常的需要,据权威机 构预测到2010年要充分应用信息技术,每个人至少需要10个IP地址,比如:计算机、笔记本、手机和智能化冰箱等。为了解决该问题开发了IPv6规 范,IPv6用128位表示IP地址,其表示为8组4位16进制数,中间为“:”分隔。比 如,AB32:33ea:89dc:cc47:abcd:ef12:abcd:ef12。 

二、IP地址分类

为了方便IP寻址将IP地址划分为A、B、C、D和E五类,每类IP地址对各个IP地址中用来表示网络ID主机ID的位数作了明确的规定。当主机ID的位数确定之后,一个网络中是多能够包含的计算机数目也就确定,用户可根据企业需要灵活选择一类IP地址构建网络结构。

A类

A类地址用IP地址前8位表示网络ID,用IP地址后24位表示主机ID。A类地址用来表示网络ID的第一位必须以0开始,其他7位可以是任意值, 当其他7位全为0是网络ID最小,即为0;当其他7位全为1时网络ID最大,即为127。网络ID不能为0,它有特殊的用途,用来表示所有网段,所以网络 ID最小为1;网络ID也不能为127;127用来作为网络回路测试用。所以A类网络网络ID的有效范围是1-126共126个网络,每个网络可以包含 224-2台主机。

B类

B类地址用IP地址前16位表示网络ID,用IP地址后16位表示主机ID。B类地址用来表示网络ID的前两位必须以10开始,其他14位可以是任 意值,当其他14位全为0是网络ID最小,即为128;当其他14位全为1时网络ID最大,第一个字节数最大,即为191。B类IP地址第一个字节的有效 范围为128-191,共16384个B类网络;每个B类网络可以包含216-2台主机(即65534台主机)。

C类

C类地址用IP地址前24位表示网络ID,用IP地址后8位表示主机ID。C类地址用来表示网络ID的前三位必须以110开始,其他22位可以是任 意值,当其他22位全为0是网络ID最小,IP地址的第一个字节为192;当其他22位全为1时网络ID最大,第一个字节数最大,即为223。C类IP地 址第一个字节的有效范围为192-223,共2097152个C类网络;每个C类网络可以包含28-2台主机(即254台主机)。

D类

D类地址用来多播使用,没有网络ID和主机ID之分,D类IP地址的第一个字节前四位必须以1110开始,其他28位可以是任何值,则D类IP地址的有效范围为224.0.0.0到239.255.255.255。

E类

E类地址保留实验用,没有网络ID和主机ID之分,E类IP地址的第一字节前四位必须以1111开始,其它28位可以是任何值,则E类IP地址的有效范围为240.0.0.0至255.255.255.254。其中255.255.255.2555表示广播地址。

在实际应用中,只有A、B和C三类IP地址能够直接分配给主机,D类和E类不能直接分配给计算机。 

三、 网络ID、主机ID和子网掩码

网络ID用来表示计算机属于哪一个网络,网络ID相同的计算机不需要通过路由器连接就能够直接通信,我们把网络ID相同的计算机组成一个网络称之为本地网络(网段);网络ID不相同的计算机之间通信必须通过路由器连接,我们把网络ID不相同的计算机称之为远程计算机。

当为一台计算机分配IP地址后,该计算机的IP地址哪部份表示网络ID,哪部份表示主机ID,并不由IP地址所属的类来确定,而是由子网掩码确定。子网确定一个IP地址属于哪一个子网。

子网掩码的格式是以连续的255后面跟连续的0表示,其中连续的255这部份表示网络ID;连续0部份表示主机ID。比如,子网掩码255.255.0.0和255.255.255.0。

根据子网掩码的格式可以发现,子网掩码有0.0.0.0、255.0.0.0、255.255.0.0、255.255.255.0和 255.255.255.255共五种。采用这种格式的子网掩码每个网络中主机的数目相差至少为256倍,不利于灵活根据企业需要分配IP地址。比如,一 个企业有2000台计算机,用户要么为其分配子网掩为255.255.0.0,那么该网络可包含65534台计算机,将造成63534个IP地址的浪费; 要么用户为其分配8个255.255.255.0网络,那么必须用路由器连接这个8个网络,造成网络管理和维护的负担。

网络ID是IP地址与子网掩码进行与运算获得,即将IP地址中表示主机ID的部份全部变为0,表示网络ID的部份保持不变,则网络ID的格式与IP地址相同都是32位的二进制数;主机ID就是表示主机ID的部份。

例1:IP地址:192.168.23.35 子网掩码:255.255.0.0

        网络ID:192.168.0.0 主机ID:23.35

例2:IP地址:192.168.23.35 子网掩码:255.255.255.0
        网络ID:192.168.23.0 主机ID:35 

四、子网和CIDR

将常规的子网掩码转换为二进制,将发现子网掩格式为连续的二进制1跟连续0,其中子网掩码中为1的部份表示网络ID,子网掩中为0的表示主机ID。比如255.255.0.0转换为二进制为11111111 11111111 00000000 00000000。

在前面所举的例子中为什么不用连续的1部份表示网络ID,连续的0部份表示主机ID呢?答案是肯定的,采用这种方案的IP寻址技术称之为无类域间路 由(CIDR)。CIDR技术用子网掩码中连续的1部份表示网络ID,连续的0部份表示主机ID。比如,网络中包含2000台计算机,只需要用11位表示 主机ID,用21位表网络ID,则子网掩码表示为11111111.11111111.11100000.00000000,转换为十进制则为 255.255.224.0。此时,该网络将包含2046台计算机,既不会造成IP地址的浪费,也不会利用路由器连接网络,增加额外的管理维护量。

CIDR表示方法:IP地址/网络ID的位数,比如192.168.23.35/21,其中用21位表示网络ID。

例1:192.168.23.35/21

        子网掩码:11111111 11111111 11111000 00000000则为255.255.248.0

   网络ID:192.168.00010111.0(其中第三个字节红色部分表示网络ID,其他表示主机ID,网络ID是表示网络ID部份保持不变主机ID全部变为0)则网络ID为192.168.16.0

起始IP地址:192.168.16.1(主机ID不能全为0,全为0表示网络ID最后一位为1)

结束IP地址:192.168.00010111.11111110(主机ID不能全为1,全为1表示本地广播)则结束IP地址为:192.168.23.254。

例2:将163.135.0.0划分为16个子网,计算前两个子网的网络ID、子网掩码、起止IP地址。

第1步:用CIDR表示163.135.0.0/20,则子网掩码为255.255.240(11110000).0。

第2步:第一网络ID(子网掩码与IP地址与运算):163.135.0.0

    第一个IP地址:163.135.0.1 结束IP地址:163.135.15.254;

第3步:第二网络ID:163.135.16.0

            第一个IP地址:163.135.16.1 结束IP地址:163.135.31.254。 

五、子网掩码和网络ID的快速计算方法

CIDR的子网掩码都是连续的1跟连接的0表示,则子网掩码有以下几种表示方法:

0000 0000   0

1000 0000   128

1100 0000   128+64=192

1110 0000   128+64+32=224

1111 0000   255-15=240

1111 1000   255-7=248

1111 1100   255-3=252

1111 1110   255-1=254

1111 1111   255

大家都知道11111111的十进制数为255,那么我们怎么来快速计算子网掩码呢?二进制的1=1,11=3,111=7,1111=15;那么 1111 1110=255-1,1111 1100=255-3,1111 1000=255-8,1111 0000=255-15这样是不是就很快呢?只要我们一旦确定子网掩码中有多少位表示网络ID,那么我们马上就可以写出子网掩码了。那么,对于1000 0000,1100 0000和1110 0000 我们又该怎么计算呢?27=8则1000 0000=128,1100 0000=128+64,1110 0000=128+64+32,所以我们不需要去记住每一个为多少,只需要做做简单的加减法就搞定子网掩码的计算。

网络ID的结果大家都知道网络ID部份不变,主机ID部分全部变为0,那么在计算网络ID时,首先看子网掩码中有多少位用来表示网络,相应在将IP 地址转换为二进制时就只转换前面几位,比如192.168.176.15/19,网络ID一共19位,则网络ID前两个字节为192.168.X.0发生 变化的为第三个字节。那么怎样快速计算出这个变化的X的值呢?我们知道第三字节只有三位表示网络ID,转换时176>128,第1位为 1,176-128=48<64,第2位为0,48>32第3位为1,剩下的计算就没有意义了,全都要转换为0,则网络ID为10100000,则网络 ID为192.168.160.0,这样计算反而出错的可能性很小。

六、 本地和远程网络概念

网络ID相同的计算机称之为本地网络,本地网络中的计算机相互通信不需要路由器连接;网络ID不相同的计算机称之为远程网络,远程网络中的计算机要相互通信必须通过路由器连接。

例1:192.168.10.14/28,192.168.10.15/28,192.168.10.16/28,192.168.10.31/28哪些是合法IP,哪些是非法IP地址?

主机ID全为0和主机ID全为1的为非法IP地址:192.168.10.15/28、192.158.10.16/28、192.168.10.31/28都是非法IP地址。

例2:192.168.10.14/28,192.168.10.15/28,192.168.10.16/28哪个不是同一网段?

网络ID相同的就属于同一网段,则192.168.10.16/28不属于同一网段。

七、子网数和主机数的计算方法

例:172.168.34.56/20,一共划分为了多少个子网,各子网可以包含多少台主机。

172.168.34.56是一个B类地址,B类地址用16位表示网络ID,题目中20位表示网络ID,则子网位数为4位,那么子网就有24次个(即从0000、0001到1111的16种变化)。

由于IP地址是32位,用20位表示网络ID,则主机ID的位数为12位,则每个子网可以包含212-2个IP地址,即可以包含4096个IP地址。

注意:为什么计算IP地址时要减2,而计算子网数目时不减2呢?IP地址减2的原因是主机ID不能全为0也不能全为1;子网就不存在这个问题。

八、 公共IP和私有IP地址

IP地址由IANA(Internet地址分配机构)管理和分配,任何一个IP地址要能够在Internet上使用就必须由IANA分配,IANA 分配的能够在Internet上正常使用的IP地址称之为公共IP地址;IANA保留了一部份IP地址没有分配给任何机构和个人,这部份IP地址不能在 Internet上使用,此类IP地址就称之为私有IP地址。为什么私有IP地址不能在Internet上使用呢?因为Internet上没有私有IP地 址的路由。私有IP地址范围包括:

A类:10.0.0.0/8

B类:172.16.0.0/12 即172.16.0.1-172.31.255.254共16个B类网络

C类:192.168.0.0/16即192.168.0.1-192.168.255.254共256个C类网络

Java面试题

  1. 重写equals方法时,必须同时重写hashCode方法?

○是√

○否

  1. 当一个线程进入一个对象的synchronized方法A之后,其它线程是否可进入此对象的synchronized方法B?

○是

○否√

  1. 下列哪个对象不可用于线程同步的实现?

○ReentrantLock

○Semaphore

○CountdownLatch

○FutureTask

○ThreadLocal√

  1. 下面哪个Set的插入和遍历顺序是一致的?

○LinkedHashSet√

○HashSet

○AbstractSet

○TreeSet

  1. 以下关于final关键字说法错误的是?

○final是java中的修饰符,可以修饰接口、抽象类√

○final修饰的类肯定不能被继承

○final修饰的方法不能被重载

○final修饰的变量不允许被再次赋值

  1. 请选择Java线程的几种实现方式?

□Runnable接口√

□继承Thread类√

□使用Excutor框架√

□Serializable接口

□Callable接口√

  1. 关于分布式系统里保证数据一致性的描述正确的是?

□可用synchronized关键字保证

□可以基于数据的版本号来实现乐观锁√

□调整数据库事务的隔离级别为串行化√

□推荐用Redis实现分布式锁√

  1. 在下列场景下,哪种排序是最快的?

场景:在一个数组里,大多数的数据是有序的,少部分是乱序的。

□冒泡排序

□选择排序

□插入排序√

□归并排序

□快速排序

  1. Redis支持的数据结构有?

□String√

□List√

□Set√

□Hash√

□Tuple

  1. 下列哪些与数据库性能优化相关?

□拆分联合索引以应对多变的SQL√

□使用外键

□Explain (Plan) √

□将嵌套查询中返回结果集较小的查询作为子查询√

□精准查询放在前,范围查询放在后面√

□尽量避免having语句√

浅谈微服务及十二要素

微服务

微服务架构是各种因素影响下的产生的一种新的架构风格。

  1. 使用传统的单体式架构应用开发系统,如CRM、ERP等大型应用,随着新需求的不断增加,企业更新和修复大型单体式应用变得越来越困难。
  2. 随着移动互联网的发展,企业被迫将其应用迁移至流行的UI界面以便能兼容移动设备,这要求企业能实现应用功能的快速上线。
  3. 随着应用云化的日益普及,生于云端的应用具有与传统IT不同的技术基因和开发运维模式,云端的庞大计算计算能力及互联网公司大量开源轻量级技术不停涌现并日渐成熟。
  4. 新的方法与工具,如敏捷,运维开发一体化,极限编程的出现。
  5. 简化的基础设施如操作系统虚拟化,容器化,基础设施即服务(IaaS),服务平台化(PaaS),以及软件即服务(SaaS)的概念和应用的深入。

受到以上各种因素的影响,微服务架构应运而生

1.    微服务定义

微服务是一个抽象统称,在不同的语境里有不同的含义。在具体的交流中,可以分为微服务架构、微服务系统、API或消息。

1.1           微服务架构

微服务架构是在单体应用高复杂度、业务单元无法拆解的背景下,为了提升交付效率和加大系统的弹性,采用将多个可独立进行开发、管理、迭代的单一功能的模块组合出复杂的大型应用系统、各功能模块使用与编程语言无关的API集合相互通讯的方式的一种新的关于系统整体结构的抽象描述,用于指导大型系统各个方面的设计。

1.2           微服务系统

采用微服务架构思路设计的系统,我们称之为微服务系统。

1.3           微服务(API或消息)

我们更倾向于把提供特定的具体的功能的可以被外部调用的实现叫做API(Application Programming Interface)或者消息,比如Rest API、ActiveMQ或者RocketMQ等。

2      微服务标准(微服务十二要素)

2.1     基准代码

一份基准代码,多份部署,基准代码和应用之间总是保持一一对应的关系。所有部署的基准代码相同,但每份部署可以使用其不同的版本。多个应用不可以共享同一份代码,可以将代码拆分独立的类库后通过依赖策略去加载。

2.2     显式依赖

通过依赖清单,明确的声明所有依赖项,在运行时,通过依赖隔离工具确保程序不会调用系统中存在却未声明的依赖项,开发环境与生产环境都应尊从。另外每个组件的依赖应该明确列出,由于多个组件存在相似的依赖,需要进行冗余依赖排除,减少版本冲突。

2.3     代码与配置分离

不建议将可配置的信息硬编码到程序中,可以存在在环境变量里,建议用配置中心存储各应用的配置,这样使用一套代码可以很方便的在不同环境上部署,启动时只需要指定配置环境,而不用改动任何代码,此配置应该与编程语言无关。

2.4     后端服务

把后端的服务当成资源。比如本地数据库,云数据库,消息服务,第三方服务,SMTP服务等,微服务系统不应区别对待本地还是第三方服务,不论使用本地服务还是使用云服务,通过URL或配置可以方便替换。禁止后端服务之间的耦合。

2.5     构建、发布、运行

严格的划分编译、发布、运行阶段,每个阶段由工具进行管理。持续集成,持续部署。如需修改运行的代码则需要重新进行构建、发布、运行三个环节,且顺序执行。三个环节可以手动执行,也可以自动执行。持续集成,持续发布一般在敏捷管理平台上进行管理。建议每个CI都只对应一套代码库。

2.6     无状态进程

应用必须为无状态应用,Session信息应该独立于应用存储,比如存储在Memcached或Redis中。需要持久化的数据应该存储于后端服务中,比如数据库mysql。在负载均衡策略上,由于应用的无状态性,所以要用轮询请求应用服务器的方式,以使各应用服务器的负载更加均衡。

2.7     数据隔离

建议只允许通过服务API 来访问服务的持久化数据,防止微服务之间隐式契约,确保微服务不能紧密耦合。不允许数据共享。微服务之间通过API或消息互相访问,也加大了微服务后台选型的灵活性,比如微服务后台数据库选型mysql还是oracle已经与服务调用者无关。

2.8     提升并发能力

进程优先于线程。通过横向扩展容器来提升吞吐能力,纵向扩展一般不推荐,比如增加内存,增加CPU核数,一般内存和CPU占用率过高都存在潜在的风险,需要优化程序逻辑。线程的使用要慎重,尽量减少线程的资源占用。

2.9     快速启动和优雅终止

在启动时应禁止自动执行的任务,及禁止同步加载大量数据,减少启动时间,这样有利于快速的对应用进行伸缩,快速响应配置和代码的变化。进程还应该在突然死亡时仍然保持健壮,比如重要数据要实时存储到后台。

2.10 开发与生产环境一致

缩小本地与线上差异,保证各环境的一致性,包括OS,容器规格,虚拟机规格,Tomcat版本,数据库版本,JDK版本,PaaS组件版本等,尽可能减少开发环境与生产环境的差异。

2.11 把日志当做事件流

应用应该把日志存储于日志云平台,不要自己存储在本地。要能够在终端看到应用的实时日志流,最好能够做到实时日志的聚合展示。通过日志要能够查询到每个服务的执行时间。

2.12 管理进程与其它应用进行使用同一份代码和配置

脚本,系统管理后台同样要用代码仓库管理,并且与应用代码保存在同一套代码库里,而且应该不受环境影响,要保证脚本可重复执行.

Mysql事务的串行化

串行读特别简单,就当成是对同一个批数据不允许并发操作,按顺序更新,插入,或者删除。

那么问题来了,同一批数据该如何界定?这是个问题。之前的看图说话中,似乎还没提到这个问题。

先看串行读,事务开启,先事务A select,然后事务B进行 update,注意,此时事务B是不可能马上提交成功的,要等事务A 提交后,事务B才会提交,这就是串行。(如果不start transaction,意味着未开启事务,那么就是自动提交,自动提交也是事务)

先看图说话:

事务A (下图B更新+1,A也更新+1)

下图为事务B 因为等待事务A的提交而超时。

基本上三种隔离级别都实验了。

对于开篇提出的疑问,“一批数据”指的到底是什么,经过实验,三种隔离级别里,都是对读取的数据行表进行隔离。

比如事务开启后先执行了select * from account,因为没where条件那就是隔离了整张表了。

所以当要求多个事务中的数据修改不能互相覆盖时,如果想用事务控制,只有串行化。这是重点!五颗星!

此时此刻应该再搞搞MVCC了。