楼市学习-最后的救市换入大城市房子的最后时刻一2015年

天涯原文整理:
楼主鹏程蛇口     微博  https://weibo.com/u/3895107933
明王的天涯帖子

由于2014年房地产进入调整期,政府相继出台了930新政和330新政进行救市。本轮房地产大救市,是最大规模也是最后一次大规模救市行动,现在看来,政策还未完全出完,如果楼市不能回暖,还会有更猛烈的救市措施出台。

此番救市之后,房地产进入“政策简单,市场复杂”的以市场调节为主的状态,以后不会再有也不可能再有如此大规模的救市行动,当然,也不会再有以往那种大规模的打压行动,因为中小城市整体过剩背景下房地产根本经不起打压。

        我们要明白的是,救市的目的不是为了救房地产,而是为了救地方财政,地方债务,地方债务已经压的有些地方政府喘不过气来,此番救市提振房地产市场,是为了缓解地方债务危机,为进入新常态下的经济转型赢得时间和空间。

         因此此番救市房价还没有上涨的城市,就再也不会上涨了,这次救市是最后一次出手机会,否则将来面对的很可能是有价无市,房价绵绵下跌,只能砸在自己手中。

必须在此番救市期间抓紧时间出掉这类城市的房子,买入一线和强二线城市的房子。此番救市,有条件入市的一定要抓紧入市,这是最后的低价机会。

  未来中国城市房价会冰火两重天,强者恒强,一线和强二线城市的房价会不断上涨,屡创新高,直到价格涨的让你绝望。而广大的三四线城市房价会不断下跌,没有最低,只有更低。
  未来,优质资产收入远高于工资收入,是一个全球性的规律。在中国人口如此众多、地区差距和城乡差距巨大、过去几十年城市化又被人为阻止的背景下,城市化的补课效应会使这一点更加突出。用不了十年,和你同样学历同样职业同样出身的人,因为买房和不买房的区别、买对房子和没有买对房子的区别,就是富人和穷人的区别、中产和白领的区别、财务自由和财务不自由的区别。

 楼市回暖,再次引发人们瞩目。在深圳、上海等一线城市,重现“日光盘”,即开盘当天即告售罄的情况,这引发了持币观望者对房价 可能又一次大涨的忧虑。

分化,是近期业界人士谈论楼市 时,使用最多的词汇。与一、二线城市楼市交易的热络相比,一些三、四线城市不为所动,楼市成交不升反降。一些城市出台力度更大的楼市刺激政策。广东佛山日 前解除了“限购令”,吸引了不少广州人出手购房。中原地产首席分析师张大伟认为,三、四线城市未来的楼市前景不容乐观:“整个中国房地产市场已经不处于同 一个周期。对于三、四线城市来说,消耗库存起码需要两年以上时间,带有投资目的进行投资,需要谨慎。”

     中国各个城市发展这么快,土地财政功不可没,你去其他国家的城市看看就知道了,中国城市发展是何等的迅速。

的确如您所说,中国经济在转型,要减少对土地财政的依赖,可转型前,要尽量的把政府债务处理掉。这也是为什么我说是最后的救市。

这轮救市后,房事会发生深刻的变化,强者恒强,一直上涨,弱者恒弱,连绵下跌。

  下面我来谈谈大城市房价会持续上涨的理由以及小城市房价不涨以及可能下跌的理由。
  精彩在后面。

 大城市房价上涨的理由:

1.大城市工作机会多,人口在持续流入,逃离北上广是伪命题。很多人不是不喜欢山清水秀、乡情浓厚的故乡,可是故乡没有足够的机会,为了就业,只能去大城市。

2.大城市能提供高端就业机会,年薪30万以上的工作基本存在于大城市,金融、互联网、大公司总部、外企中国公司总部等高端就业岗位只能存在于大城市。

3.工业社会,工厂是创造财富的中心,工业、矿业发达的中小城市也很富裕。而现在是资本社会,货币为王,大城市中心的写字楼是财富中心,产业只能为资本服务。大城市能够创造更多的财富。

4.城市化早期和中期,农村人口流入城市,各城市都有发展机会,表现在房地产上就是各城市房价普涨,而到了城市化后期,是人口从中小城市流入大城市,一个城市只有人口持续流入房价才能上涨。

5.中国人口众多,水资源、土地资源、各类矿产资源短缺,只能发展节约资源的集约型经济,这种基本国情决定了中国的城市化只能是类似日韩两国的以大城市圈为代表的都市化,大多数人口集中生活在少数几个大都市中。

6.中国人有重视家庭、重视房子的传统,孩子工作在哪里,父母退休后就在哪里。一些人离开家乡,到大城市读书、工作,买房,进而是父母随迁到孩子工作的大城市,整个家庭积累一辈子的财富会从小城市转移到大城市。

三线以下城市面临的问题:

1.三线以下城市过去的房价上涨主要是过去住房的短缺以及外来人口的涌入造成的。随着供给量的增加,部分城市的住房供应已经过剩,面临去库存的压力,房价有下跌的压力。

2.三线以下城市土地充足,新城规划体量大,供给量巨大。

3.房价不上涨,还乡团回家购买的欲望不强烈,失去了一个购买主力军。

4.三线以下的就业机会大多集中在制造业,几乎所有制造业的产能都已经过剩,未来面临消减产能的压力,随着就业机会的减少,人口不仅不会增加,更可能会减少。

5.随着计生政策威力的显现,人口红利消失,流入城市的人口会持续减少,未来各个城市间会发生争夺人口的战争,小城市在人口吸引力上明显的逊于大城市,人口从小城市流向大城市会长期存在。

6.一个人口流出的城市房价注定缺乏上涨的压力,甚至可能会出现下跌。

 从日本的情况来说明一下大城市房价:

从黑龙江黑河到云南腾冲连线,这条线(就是著名的胡焕庸线)的东南部国土面积大概320万平方公里,居住着全国94%以上的人口(12亿2千万)。日本国土面积是37万平方公里,人口1.2亿,中国胡焕庸线以东的人口和面积都相当于日本的10倍,中国是放大了的日本。

日本和中国同属于东亚文化圈,同样是人口稠密、资源短缺,经济结构同样是以制造业为主。日本的房地产发展历史对中国有借鉴意义。

日本全国28%的人口居住在东京都市圈,日本的房地产市场,可以割裂分成二个市场:东京,非东京。

很多人都知道日本“房地产”狂潮。但进一步细心读阅史料的人,才会发现,这个狂潮,绝大部分都发生在东京。

在东京以外的地方,哪怕在大阪,福冈这样的地方。房地产价格也不是太高。可能只有东京1/3的价格。和青岛也差不多。

而在日本更低一级的行政区,在一些乡和镇,已出现了无人居住的村落。房地产甚至完全不值钱。一百万日元就可以维修拿走。

 除了顶级富豪和底层赤贫,房子注定是一个人一生最大的一笔花费,最大的一块资产,值得一个人花费足够的精力去研究,去了解,从而做出正确的决断。

遗憾的是一个人可以花1周时间买一件1000元的衣服,可以花一个月的时间买一辆20万元的轿车,而吝啬花费足够的时间去了解一套300万的房子。

本次救市是最后的救市,以后的房产市场基本是市场说了算了。

以后是强者恒强,弱者恒弱,冰火两重天。今年是以较低价格买入一线房产的最后机会。

所以趁着下半年市场成交火热,卖出三四五线城市的房产,买入一线及二线强城市的房产。

美国房价高的城市只有3个:

1、纽约:美国第一大城市,世界特大城市之一,是美国最大的海港、金融、贸易和文化中心。 位於美国东北部海岸哈得逊河口。 沿海贸易额居全国第一位。

2、洛杉矶:美国第二大城市和重要海港。位於加利福尼亚州西南部、洛杉矶河边。洛杉矶是美国西部工商业第一大城,在太平洋沿岸各港口中, 洛杉矶远洋货轮的吞吐量占第一位。 洛杉矶也是美国西部的旅游中心,迪士尼、好莱坞闻名世界。

3、旧金山:美国第五大城市,第二大金融中心,世界最大的科技创新基地硅谷所在地,城市经济以服务业、商业和金融业为主,是太平洋岸证券交易所和美国最大的银行美洲银行总部所在地。

除了以上三大城市,房地产在美国,并不是一项稀缺资源。美国的人均居住面积,大约在80平米左右。基本不存在“房痴”,“房奴”。
以美国一套典型的小镇上的郊区房子而言。售价25万美元。大概分三部分组成。
其中,建筑成本8万美元,地价8万美元,“建筑许可”8万美元。建筑许可,这一块的成本,也是美国国家主义的典型失败。在美国造新房子,你必须得到左邻右舍的同意。包括新建房的高度,颜色,建筑风格,都有严格的限制。这样做的结果,最终是推高了房屋售价。但无论怎么说,我们可以看见的是。在美国,“房地产”是完全不稀缺的。地价和建筑成本的比例,大约是1:1

上海、南京、无锡三个城市,人均GDP,人均收入相差无几,处于同一水平线上,而房价却差距巨大。

说明房价与人均收入关系不大,与是否能够提供高端岗位机会关系更大。

 自住买房,一定要买市区生活方便的房子,即使贵一些也值得。不要买郊区房子,配套不好。

大多数年轻人买房,第一次都是在郊区买新房,然后过几年,小孩读书的时候,才发现周边没有好学校,于是急匆匆的换房到市中心,无形之中增加了成本。
所以买房,建议买市中心的二手房,生活读书都方便,首付不够,可以买小点的,旧点的。即使房子旧点,面积小点,都不是问题,关键是满足自己生活需要了。以后有条件了,再换大房子不迟。

楼市学习-变化的时代里要有忧患意识

一位70后的感慨:下半辈子我会陷入贫困吗?

文/刘黎平   南都记者

我一直是个有着忧患感,却始终未走出忧患的人。

从一个小悲剧说起吧。

十多年以前,听家乡人说,父母生活劳动过的生产队,有一位长我十岁左右的大哥,在铁路旁电线杆上贴假证广告,被警察追赶,中枪,还算幸运,打在腿上,之后扭送回乡。

吃了子弹,在我们当地是一件很不幸、很耻辱的事,怨妇骂丈夫时,最严重的一句话就是:“红炮子穿心的”。这位老乡的遭遇在当地引起的反响可想而知。

老乡姓毛,外号光头哥,曾何几时,他们毛家曾是方圆十来里的“显族”。

光头哥父亲名字中带一个“敏”字,职业是漆匠,人称“敏漆匠”,手艺祖传,传到他手里,不知是第几代。

从他所在的生产队往外走十公里,没有第二个从事漆匠手艺的。他所从事的产业,其附加值,远远高于社员们在地里刨一锄,挖一铲的劳动,他很为此骄傲,用了一番很形象的话来概括自己的成就感:“我虽然是农民,可一辈子没下田沾过泥巴沾过水。”

那个时代我所生活的农村,虽然极其贫困,社员们经常用地瓜当口粮,然后,敏漆匠家中顿顿有白米饭,天天能喝酒,坛子罐子里的腐乳、辣椒酱,墙上的腊肉干,没断过。

异于常人的富贵,全源于他手中的活儿:刷漆。

敏漆匠很豪爽,很大度,我们家在1979年回城后,将乡下的房子作价一百来元卖给他家。后来,我家请木匠做了一个衣柜,请了一个蹩脚漆匠,刷得实在对不起行业平均水平。

敏漆匠听说后,立即叫他两个儿子进城,吩咐说:“你们帮老乡刷好柜子,一分钱都不能收,包括油漆成本。”

这种大度和豪爽,半源于性格,半源于行业的骄傲。因为,我大度得起,豪爽得起。

再过十年,进入上世纪九十年代,进城的乡亲和父母聊起敏漆匠,皆叹息:漆匠家中光景,泯然众人矣。

又数年,则说:漆匠家中光景,不如众人矣,儿子孙辈得出去打工了。

父母听了有些惆怅,很为这位生产队显族的没落伤感,我当时是一位师专生,在旁边听着,全是一种局外人的感受:时代在前进,你不前进,多少有点活该。

可惜当时年纪小,不知世道有多艰难。

父母在1980年前后回城,父亲在学校工作,母亲进入了一家让人眉毛都能长三寸的企业:县五金交电化公司。在那个买一辆凤凰牌永久牌自行车都得求爷爷告奶奶的时代,这家单位的荣耀有多大,用头发都可以想象出来。

在我儿时的记忆中,那是一个销售行业工人无忧无虑,甚至有点嚣张的时代。

他们的称呼本来就是一种荣誉,不叫售货员,不叫服务生,而是堂堂正正的“营业员”。

1984年春晚,张明敏的“中国心”红遍大江南北,而春晚第二天大早,第一个用收录机满大街播放的,就是县五金交电化公司。那样霸气的分贝,那样高大上的气势,感觉好像张明敏是在五交化公司演唱似的。

这也算是一种传播的优势吧。

记得当时我去上学,从播放着“中国心”、“回娘家”的营业大厅里走出来,上世纪八十年代国有销售企业的那种荣誉感,也延续到我这个小学生身上,让我有如同从中南海走出来的豪迈感。

有时候,在盛夏的夜间,公司的小伙子们在营业大厅里大分贝打开电视机,看全国武术锦标赛直播,因为电影《少林寺》的关系,那时候的武术比赛颇有粉丝,小伙子们一面喝彩,一面喝汽水,脸上洋溢着幸福得无比张扬的笑容。

当时,所有的人都相信,他们这种自豪而幸福的生活,会持续下去,他们的明天也就是今天,他们的今天也就是明天,反正处在同一个领域:幸福。

而且,按照当时的就业思路,这种幸福会延伸到我们70后身上,因为当时还流行一个职业接班制度:顶职。

那时的公司开会,很少谈及具体的业务,诸如营业额,利润,公司经理作报告,主要内容是讲政治,讲新时期的大好形势,那语气,完全是党委书记作政治报告。

难怪当时一部名为《子夜》的电影,是根据矛盾的同名小说改编的,让影评家吐槽:电影的主人公哪里像民国上海滩的资本家,完全是党委书记在做报告吗。为什么?是当时的经济形态决定了艺术形态。

种种的骄傲和豪迈,都来自于行业的垄断性特征,站在高处的人,总是豪迈而幸福的。这和家乡漆匠为什么豪爽、大度,都有同一个缘由:行业的独一性,不可替代。

因此,那时销售行业的工人,微微地有点嚣张,有点任性。

姑且举一例:

五交化公司有一家专门卖化工产品的门市部,我母亲曾在那里工作过。一位同事阿姨,胖胖的,坐在柜台里懒得动身。某日,有位农民来买货,问:“同志,请问有土红吗?”售货员懒懒地回答:“没有土红,只有铁红。”

其实,土红和铁红就一回事。

这恐怕是当时销售行业态度的一个生动写照。

傲慢,来自于行业的独一性。

然而,不久,我就亲眼看到和感受到这个行业的寒冬。

上世纪九十年代初,我考上大学,虽然只是个师专,但是当时全班一百多号人(有大量复读生),只考上九个。

母亲公司的人都很高兴,有一位识时事者,很真诚地祝福说:“张大姐,你的崽争气,考上大学,又是教师,以后就不用像我们这样担心行业会垮掉,公司子弟能读书的不多,骄傲,蛮横,不学技术,现在尝苦头了,你们家小刘不错,争气,不会进入下岗大潮。”

彼时关于五交化公司会垮掉的传闻,一波比一波高,有时候公司员工会自我安慰说:“不会的,肯定不会,我们是国有企业,我们的干部可以直接调到县委当领导,都是国家工作人员,政府怎么能让国家工作人员没饭吃呢?”

员工们还在用计划经济时代的身份来安慰自己。大家都有危机感,但是谁也不知道怎样对付危机。

然而,寒冬还是在危机感中如实地降临了。

我母亲在公司垮掉之前退休了,领到了退休工资。但是绝大部分中年壮年员工,都在这个时候忽然失去了手中的饭碗。

母亲描述说:公司开了最后一次员工大会,宣布公司不行了,除几个留守人员负责公司房产和租赁事项外,大家都散伙。老员工们痛哭起来:以前私人和家庭有事,可以找公司解决,以后,我们有事,找谁去?

那一次,没有几个人走出去,尤其是那些年过四十,上有老下有小的男性领导,他们已经来不及走出去,无法再学习新的技能,无法找到一种与以前的体面相称的工作方式。

公司有一位营业主任,个子不高,且隐其名,三十来岁时当上公司领导,意气风发,也有点得意忘形,见了普通员工,爱理不理。下岗后,一切的官架子,都转变为在闹市炒米粉的姿势。

当时我在家乡教书,每次经过农贸市场,看到门口这位曾经指点江山的领导在满头大汗地一手执锅,一手执铲,系着污垢满是的厨布,在那里从事第三产业的时候,心里像承受核弹爆炸一般,升起巨大的蘑菇云,这朵蘑菇云就是:忧患感。

我不能像我的叔叔、阿姨辈那样,在一个兴旺的时代,被捆在一个没落的行业上,被其活活耽误。对于这个时代,他们也曾鼓掌,也曾欢呼,然而,他们却在鼓掌和欢呼中憔悴和凋零。

我的同辈中也有,有一位小学同学,顶职在一家国有销售公司工作,后来娶妻,家居电器都买好了,结果碰上公司倒闭,新娘不干了,不来了。

下岗女员工,是那时人民教师配偶的一个重要来源。教师钱不多,但稳定,女公务员不稀罕你,只好和下岗女工互相将就吧。

娶妻和我学历不对称,这也让我很忧患。

那时的我,好像“平凡的世界”里的朱少平,不安于平淡的乡村教师生涯,要走一条异样的路,于是考研,以我鲁钝的资质,考了三次才考入暨南大学文学院。

毕业,我进入媒体,纸媒界。

我骄傲地认为:我终于走了一条和前辈们异样的路。

每年回家,和父母走在大街上,遇母亲的同事,父母都会骄傲地介绍一番:我崽,如今在报社当记者。

母亲同事们,那些曾经在盛夏夜,在公司营业大厅一面喝酒,一面看武术锦标赛的一群,如今用仰慕的眼光看着我,我如同在玫瑰色的云端里。

我进入纸媒,并不只是虚荣心使然,也是一种使命感使然。我喜欢文字,喜欢传播文字,喜欢很多的人感受到我文字里散发的热诚、激情和那么一点点勉强称得上是智慧的玩意。

我是如此地狂爱码字,2000年的年底,2001年春节前夕,我许下一个愿望:希望我的名字每天都能在印刷品上,几十万甚至上百万地传播出去,果然,满天神佛,列祖列宗,听见我真诚的呼唤,我进入一家大纸媒集团,成了经济新闻部的编辑,每天报纸左上角都印着我的大名:刘黎平。

前辈们碌碌无为,靠着国家特殊的垄断经济形态过着舒心的日子,这是一种耻辱,人的落寞,往往是因为缺乏责任感,使命感,我这个70后的小知识分子,和他们那帮倒霉蛋是不同的,我是一个非凡的人物。

说这话,似乎有点自命不凡,但是,进入新闻行业的人,有几个是自命平凡的呢?

说实在话,除了父母亲人师长,我最感恩的,就是我所从事的这家纸媒,广州的一家巨型纸媒。一些离开它的同事,多多少少向我抱怨过它,但是我始终没有说过一句抱怨的话,不是谨慎,而是真诚。

这家纸媒,不只是一个饭碗,更是一个盛放理想的容器,它实现了我的理想,让我署名的文章每周几十万地向外传播,让我走在路上能遇到粉丝,让我能出版几本不太畅销的书。

这个世纪初,我进入纸媒时,正是如日中天的时期,广告收入全国报业第一不说,居然还胜过正在兴起的芒果台。纸媒的广告收入超过几乎同级别的电视台,这在如今是不可想象的。

我那时也不能说没有危机感,忧患感,因为我们经常要从网上找最新信息来源,记者们要等网上的央行加息减息消息,看新闻,往往第一时间上网,然后才考虑报纸。

然而,我的忧患感,仅仅停留在纸媒与网络平等竞争的层面上,报纸在新闻传播领域,虽然将来不是一个独一无二的存在,但至少是一个较大较强的存在。

而且,劳动人民对于报纸质朴的情感,似乎也对我有着心理抚慰的作用。

记得有一天晚上,十二点左右,上了班回家,叫了一辆的士,司机知道我是报社的,很羡慕地说:“报纸好啊,国民党要办,共产党也要办,反正缺不了你们。”

这句话胜过千万句经过精心策划,引用了海量数据的精英人士的报告,人民如此看好我们,我们干嘛要忧患呢?

其实,这位司机大哥的话,有一个词要替换,就是“报纸”要替换成“新闻”。

所谓的反正缺不了我们,这个我们,其实应该是职业化的新闻群体,而不是具体的我们的这一群个体。

没想到这个行业,广告在呈现断崖式的下滑,甚至能听到断崖的声音,这声音来自于工资卡,很多家纸媒已经在传播这种声音。

随着这种声音到来的,是很多纸媒精英肉身的死亡,不明白为何行业的式微,要以人的生命作为祭奠和注解,莫非这就是共业?就是劫数?

有一回参加儿子的家长会,一位女家长,也是同城报纸的,她跟我说:你们已经算幸运的了,还能在账面上没有下滑迹象,年终奖季度奖照发,尽管购买力不可同日而语,我们已经很多人在家里闲着,每个星期做不了几个版,薪水实在是很没面子。

开完家长会,我牵着儿子的手,走在学校前面的林荫大道上,看着他好奇地问我:爸爸,我们什么时候买路虎,我们什么时候换电梯楼。

看着他忽闪忽闪的眼神,充满着对父母未来,对自己未来的憧憬,我忽然有点紧张,我亲爱的孩子,你知道吗?爸爸的下半辈子可能陷入贫困。可能你得在这个贫寒的家庭里长大,如果你不够走运,不够努力,可能还得将这种贫寒延续下去。

有一部美国短片小说,讲一个小孩听说班里要捐助贫困家庭,善良的他也拿了东西捐出来,结果老师很无情地告诉他:“某某同学,你不用捐献,因为学校捐助的,就是你家。”当时那位孩子愕然之后的泪花,会是怎样一种心痛呢?

忽然担心,自己的孩子,也会冒出这样的泪花。

我惊恐不安地悲伤起来,所有曾经有过的使命感、责任感,此刻被生存危机感冲刷得荡然无存。

我想起家乡曾经富贵的漆匠,他的儿子在铁路旁贴广告挨枪子,想起母亲公司那位曾嚣张不可一世的业务主任在闹市满头大汗炒米饭,我的下半生会不会像他们一样呢?

我当时引以为警示的,就是我如今所面临的。

引用我曾经写过的一部玄幻小说:《一位史前暴君的笔记》,里面有这么一番话:“年幼的时候,我以为我能拯救这个星球;年少的时候,我以为我能拯救这个帝国;年青的时候,我以为我能拯救这座城市;中年的时候,我发现我连自己都拯救不了。”

悲哉斯言。

幼稚的儿子,目前不能感知我的危机感,就好像当年的我不能感知父母叔叔阿姨辈的危机感。

我前几年就有个担心,担心在媒体界,会出现像产业工人那样的退出潮流。如今的这一群,是高知识高素养的一群。

这种潮流,冷眼去看,不是某一个政策的失误,不是某一个人物的品质问题,而是一种无法拒绝的潮流,一种无法用失误和卑鄙去谴责的潮流。

它总会来,它总会发生,它总会选择某一人群,如果你不幸被选中,而且不幸在人到中年被选中,你能做到的,似乎只有跟着沉船上的老鼠逃生。

不要嘲笑上一代人的落魄,因为很可能你会成为他们。

不要说“人穷志不穷”,物质上穷了,精神也会跟着沦丧。即使在提倡越穷越光荣的时代,一个生产队里,最穷的那一户也是受嘲笑最多的一户,更何况今日。

伴随着对下半生贫寒的恐惧,还有对光荣感失去的恐惧。

我们很可能成为被照顾的一群,拿着国家的救济过日子,一旦想到这个,我忽然明白,欧美那些高傲的曾经的精英,为什么宁肯在地铁口搞杂耍,也不愿意去领救济金。

士可杀不可辱,在市场经济社会还是存在的。因为他们不舍曾经有过的一份光荣感。

漆匠、营业部主任,失去的也是一份光荣感。

纸媒的人,如今从事的新营生,可谓五花八门,搞厨艺,卖“心灵鸡汤”,从事童书推销,或者跑动漫业务,或靠一栋大楼收租,这个社会只要不懒,不太蠢,饿不死人。

然而,那一缕夕照般的职业荣誉感,却已经苍白,渐渐沉入昏暗。

早知道如此,不如早一点去炒粉,去卖菜,去开班,在这些行业早一点折腾经营,凭着当年考入名校的智商和毅力,或许早就开上连锁店,当上土豪了。

还有一条途径,就是理财。

你不理财,财不理你,然而,凭借你在新闻界积下的那点子银两,在失去营生行业的情况下,它们的利息完全不够你保证下半辈子的开销。

世界上没有永远不下跌的股票,没有永远高利息的理财产品,更何况你的基数也就那么一点点,要跟上通胀的速度,它们得翻倍地增长,有这样的事吗?扪心自问一下吧。

还是说说职业荣誉感吧。

新闻在碎片化,在个体化,新闻传播主体也在碎片化,个体化,新闻从业者想要保持那份荣誉感,使命感,在保持主业的同时,微信是维持这种感觉的最合适平台。

问题是,这种职业感觉可能会延续下去,但往昔的那一点点收入上的优越感(其实也很不实在)却再也维持不下去。

阅读量就算屡屡达到100000+,粉丝一万、两万地涨到十万,可是大部分人除了在朋友圈,在手指的划拨中获得一种数字刷新上的快感之外,真金白银,一分也没有。

尤其是本人这种,纯粹是赚吆喝的。觉得和当年在中学办文学社,分发那些布满浓稠油墨的文学小册子没啥子区别。

对整个行业,我一直是个路盲,但我对那些口水救世主也没有什么信心。

世上从来没有救世主,也没有先知先觉者,一种新的行业形态,谁都预言不了,就好像从来没有经济学家能预言到经济危机一样。

听过很多的关于新媒体的报告,讲座,然而到目前为止没有见过一个有说服力的例子,就算是占了威权力高度的澎湃,听说点击量也在断崖式的下崩。

新的新闻形态,它一定有,一定有它的理存在着,就好像朱熹说的:凡是事物,事先一定有一个理存在。

然而,世界是神秘的,不可知的,谁都摸不到这种新媒体形态的理,谁都不能准确描述它的具象,谁都说不清楚它何时来临。

就好像罗斯福新政,谁都以为是他挽救了美国的危机,谁都没有想到是一场超规模的战争挽救了美国的经济。(注:罗斯福、二战并没有挽救美国)

是二战挽救了美国,挽救了西方,然而,在这场挽救的过程中,是亿万百姓的痛苦和士兵的牺牲。

我们新闻人摸索着走向那个新的媒体形式,没有人能说清楚这个摸索过程和未来的情状,但可以明白的是,我们也要经历新闻的“二战”,会有很多牺牲,很多痛苦,很多彷徨,或许不幸,只是不知道谁会面临这些人力与时代力的摩擦。

作为自封的太史,我只能暖男式地说一句:摸索前进的路上,我们保重。

楼市学习-从教师讨薪现象洞察到地方债务

为什么各地频现教师讨薪?原因就两字:没钱,有些地方债能随时惊出人一身冷汗
作者: 智谷趋势
2018-06-04 20:47
财政真的有点紧

◎智谷趋势(ID:zgtrend) |  旺角黄局长

 

原以为只有农民工才是讨薪运动的扛把子。一夜醒来,教师队伍也不再拿着铁饭碗了,显得比弱势群体还要弱势。

 

搞得有点今夜人人都是六安人的感觉。

 

先是安徽六安沦陷,然后贵州毕节,湖南武冈……

 

别以为这是几点星星之火,以安徽省为例,有十个城市截止去年底就没有发放政府文件白纸黑字写清楚的一次性工作奖励。

 

别看中国GDP已飙升至82万亿、成为全球第二大经济体,其实我广大五六线城市外强中干着呢。

 

再苦不能苦孩子,再穷不能欠教师啊,连教师们的待遇都落实不了,恰恰反映了基层政府正面临着一场严重的财政危机。

 

一边是揭不开锅的财政收入,一边是债台高筑的政府性债务,谁也不知道它什么时候就成了炸雷。

 

大历史的进程往往就隐藏在小细节中。或许十年之后再回首,六安教师“讨薪”风波会成为观察地方债的一个标志性事件。

 

01

穷。地方是真的穷。

 

六安市金安区、裕安区多名教师为了讨薪让这个城市一夜之间举国皆知。

 

新京报去采访时,六安方面回应称,安徽省虽然有规定“省辖市可结合各自经济社会发展状况及相关规定对本地机关事业单位的一次性工作奖励予以规范”。但金安区、裕安区根本就没有能力出台这个奖励。(虽然)市直公务员和事业单位的老师发了……也是调查考核了一年时间才决定。所以这个事情非常复杂,财政负担非常重。

 

说到底,就是地方财政够呛。

自2015年以来,六安市的一般公共预算收入远不及支出的1/3,长年靠上级税收返还、转移支付和发债度日。

 

表面看,最近几年六安市的固定资产投资额度还是挺风光的,除了2016年短暂下滑一点外,这辆拉动经济的马车头一直在攀升。

 

但实际上,这种递增的投资额度,其拉动GDP增长效果已后继乏力。由于工业转型升级和产业结构调整跟不上,六安市的投资效果系数(每单位固定资产投资所增加的GDP)逐年下降。

 

根据六安市统计局的数据,2011年六安市投资效果系数0.282(深圳大概是0.68), 2017年跌到仅有0.088,仅相当于六年前的31%。

 

换句话说,2017年六安砸下1200亿元固定资产投资,所增加的GDP其实跟2011年490亿元的效果是差不多的。

 

六安的经济运行,已完全陷入了“高投入低产出”的困境,而且是越陷越深,难以自拔。

 

到了今年,六安市的经济直接走入了冰川时代。

 

一季度,全市900多家规模以上工业企业(年主营业务收入超2000万元)中,亏损户数就高达147家,比去年同期多了66家,亏损面为16.1%。利润额只有可怜的13亿元,同比下降24.5%。

 

六安市统计局承认,2018年一季度经济效益下滑明显,主要是三大行业不景气:

 

黑色金属矿采选业实现利润2302.2万元,同比下降93.6%

 

文体和娱乐用品制造业实现利润1846.5万元,同比下降58.8%。

 

计算机、通信和其他电子设备制造业更是直接亏损,达3138.7万元。

 

02

 

不单是六安,教师讨薪大多发生在中西部地区。

 

2月份,贵州毕节市、安顺市的部分县中小学教师们迟迟拿不到2万元年终奖,这笔钱对他们来说不是小数目,他们奔走呼告,四处撞墙。

 

5月5日,湖南武冈市上千老师讨薪惊动了当地政府。

 

截止去年底,整个安徽省还有淮北、马鞍山、宿州、蚌埠、宣城、铜陵、阜阳、淮南、滁州等城市没有发放一次性工作奖励。

 

教师法规定,教师的平均工资水平应当不低于国家公务员。地方政府宁愿扛着违法的嫌疑,也要咬住牙拖拖拖,是什么令他们迟迟不肯开锅?

 

两个字,没钱!

 

贵州毕节这三年的地方一般公共预算收入增速分别为-7.3%、4.7%、12.3%,看起来好像不错,其实只是因为前几年财政收入跌的实在是太厉害了,稍微一点止跌回升,数据就显得很靓丽。

 

事实上,2017年毕节的地方一般公共预算收入为123.84亿元,比4年前的水平还要低呢,2013年还有125.62亿元。这座城市是由阴转阳了,但并没有完全恢复过来。

 

除了阜阳之外,目前被曝光欠薪的十几个城市一般公共预算收入增速都非常乏力,基本都处于下滑通道。像滁州、蚌埠、宿州、淮北的增速从往年的两位数直接跌到个位数。马鞍山、武冈、铜陵三个城市更不忍睹,直接是负增长了。

 

03

 

为什么这些地方的造血能力这么弱,好像集体被抽掉魂似的?

 

我们先来看一张表——

 

这些城市都有一个共同的特征,就是固定资产投资与GDP的比值高得吓人。没有一个低于90%的,甚至有一半以上的城市高于100%。

 

在上一轮经济周期里,这些五六线城市长期依赖投资拉动经济增长。当北京(32%)、上海(24%)、广州(28%)、杭州(47%)、苏州(33%)、无锡(47%)等沿海城市早已转型换挡,走上内生增长道路上,这些城市还是一条路走到黑。

 

这种传统发展模式与中国大环境变化之间的错位,形成了一个巨大的悖论:投资越大、效应越低。

 

高科技项目引不进来,但为了GDP还是硬上,大量投资停留在低端化的产业结构,导致产品附加值较低,投资效率偏低,对财政收入的刺激也就大打折扣了。

 

找不到核心驱动力,就算是低水平的重复投资也照单全收,最终引起产业同质化,大量资本沉淀在产能过剩的产业。营改增之前,政府才不管企业亏不亏损,只要开门营业了就可以收营业税,所以就算经济下滑,政府也能撑一撑。现在改征增值税后,企业只要没活干,就无增值税可收。财政收入之困难可想而知。

 

今日的中国早已不是当年那个中国了。来个大项目,也够不了当地吃多久。

 

这还不是最可怕的。

 

如果砸下大把钱只是收上来的税少一点,我们也就认了。更要命的是,很多投资项目都是地方政府从银行借贷搞起来的,或者是政府以担保、明股实债的形式诱导企业下水的。

 

那些投下去的钱,最终都变成了地方政府直接的、或有的债务。这些地方政府性债务像雪球一样越滚越大,累计的风险也越来越突出。

 

04

 

在这种背景之下,你再去看一下六安市的地方债情况,就非常值得玩味了。

 

这几年,六安市政府的负债率大概是30%,低于国际警戒线60%。但衡量地方债的风险程度,从来都不能只看表面上的数据。

 

这就好比一个人的体重、身高完全符合标准,但这并不代表他的身体状况就健康,内在免疫力一旦贫弱,就算是一个普通流感也能把他打趴下。

 

同样的道理,地方政府如果自我造血能力弱,就是负债率低于60%,也有可能无力还债,眼睁睁地看着债务崩塌。

 

更何况,对于负有偿还责任的债务这些必须公开的数据,政府往往会加以粉饰使之合规。而那些隐藏在背后的担保责任债务、救助责任债务,通常讳莫如深,加上这两块,每个地方政府的债务都会更高一些。

 

在经济下行的情况下,你根本不知道哪个链条会率先断裂。

 

1月11日,云南某省级融资平台违约,这是中国首例省级融资平台炸雷。

 

4月27日,又一个省级融资平台深陷兑付危机了,地点,发生在同样有着投资驱动模式的直辖市天津。

 

5月10日,天津最大国有房企天房集团惊爆1800亿负债,业界普遍认为,一旦爆发将炸伤大半个中国金融圈。

 

省级融资平台的融资能力一般数倍甚至数十倍于市县级融资平台,如果连这些平台都扛不住炸雷了,这些GDP不及天津、云南的十分之一的五六线城市,岂不是更令人担忧?

 

2017年5月,六安市就率先给下边各个县区发了一份《政府性债务风险应急处置预案》,从预警、定级、应急、处置、保障等方面做出了事无巨细的规定。

 

这篇洋洋洒洒一万字的宏伟巨作,充满了爆屏的危机感。翻译成人话就是:

顶不住了千万别硬抗,提前一两个月吱下声。万一真炸雷了,而且还是个大大雷,你们就直接飞到省里汇报吧,不用看我面子。那些负有偿还责任的债务,白字黑字都签了,流着泪也要还。有担保责任的债务,撑死就还 1/2,不能再多了,那些有救助责任的债务,你们看自己兜里,有多少就给多少,重要是要把事情摆平了,群众情绪要稳定。

 

前几天,全国人大财经委副主任委员贺铿在北京某论坛的一番讲话引起轩然大波。他说,中国的地方债大概是40万亿,但地方政府就没有一个想还债的。

 

“现在要让他还债,他说我工资都发不出来,财政困难得很,怎么办?所以现在欠的这些债不说还本,还息许多地方都还不起。”

 

有人说,要化解这些天量地方债,要么借新还旧,要么就是发行货币稀释,最终通过通胀由百姓买单。

 

其实还有另外一种手段。今天中国正在加速新一轮的经济结构调整,典型如雄安新区、海南自贸港以及即将落地的粤港澳大湾区,他们的转型升级将给全国带来示范效应和溢出效果,推动各地形成硬核的经济驱动力,最后在发展中解决问题。

 

难度虽大,但并非没有可能。

 

割韭菜?不存在的!关注牛叫兽读财,回复股票名字,查询港资对个股的持仓情况,能比99%的人先跑路~!

智谷旗下投资理财公号

软件分析模式-概述

分析模式:可复用的对象模型


 

分析模式:可复用的对象模型
原文书名:Analysis Patterns: Reusable Object Models
作者: (英) Martin Fowler
译者:樊东平 张路 等
书号:978-7-111-30530-9
上市时间:2010年6月

 

作者简介:

Martin Fowler 在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面,都是世界顶级的专家,现为ThoughtWorks公司的首席科学家。 ThoughtWorks是一家从事企业应用开发和集成的公司。早在20世纪80年代,Fowler就是适用对象技术构建多层企业应用的倡导者,他著有几 本经典书籍:《分析模式》、《UML精粹》和《重构》等。

 

内容简介:
《分析模式:可复用的对象模型 》的作者Martin Fowler是国际著名的OO专家,敏捷开发方法的创始人之一,现为ThoughtWorks公司的首席科学家,本书是作者的代表作之一,深受业界专业人士和广大读者的好评,经久不衰。
《分析模式:可复用的对象模型 》讲述各种分析模式(即来自概念性业务模型的模式)和支持模式(即讲述如何使用分析模式的辅助性模式),把论述重点放在介绍面向对象分析和设计的最终结果—即模型本身。作者透过平实朴素的语言,将自己丰富的对象建模经验与读者分享,使读者可以马上采纳这些经验性模式。
本书适合的读者范围非常广:面向对象的计算机分析人员和设计人员(尤其是那些参与系统分析的人员)、数据建模人员、编程人员以及专业的软件工程师都可以从本书中获得宝贵的知识和经验。

本书赞誉:
“《分析模式:可复用的对象模型 》是对不断发展的模式文献的一个重要贡献。它捕捉来自不同领域的深奥的对象建模专业知识,形成一个模式目录。这些领域模式将有助于你解决不同领域中具有挑战性的建模问题。”
———《设计模式》作者Erich Gamma
“Martin Fowler为我们给出答案,而不仅仅是一个可以找到这些答案的过程。在《分析模式:可复用的对象模型 》中,透过作者平实朴素的语言,你将找到自己下一个业务对象模型的重要内容。”
———Ward Cunningham
“就像‘四人帮’在他们的经典著作《设计模式》中总结出了通用的设计模式,Martin Fowler在这本让人期待已久的书中为我们总结出应用领域的诸多模式。《分析模式:可复用的对象模型 》是从事面向对象业务建模和业务过程重组工作的所有分析人员和设计人员的必备之书。”
——Donald G. Firesmith

 

目录
Ralph Johnson序
Ward Cunningham序
前言
第1章 绪论 1
1.1 概念模型 1
1.2 模式世界 4
1.2.1 Christopher Alexander 5
1.2.2 描述格式 5
1.2.3 关于模式的抽象程度 6
1.3 本书中的模式 7
1.3.1 建模实例 8
1.3.2 模式的来源 8
1.3.3 跨领域的模式 9
1.4 概念模型与业务过程重组 9
1.5 模式与框架 10
1.6 本书的使用 11
第一部分 分析模式
第2章 责任模式 17
2.1 团体 18
2.2 组织层次 19
2.3 组织结构 21
2.4 责任 22
2.5 责任知识级 24
2.6 团体类型泛化 26
2.7 层次型责任 27
2.8 操作范围 29
2.9 职位 31
第3章 观察和测量模式 33
3.1 数量 34
3.2 转换率 36
3.3 复合单位 37
3.4 测量 38
3.5 观察 40
3.6 观察概念的子类型化 43
3.7 观察方案 44
3.8 双时间记录 44
3.9 被否决的观察 45
3.10 临床观察、假设与推理 45
3.11 关联观察 46
3.12 观察过程 48
第4章 针对公司财务的观察模式 52
4.1 企业片断 53
4.1.1 定义维度 57
4.1.2 维度的属性以及企业片断 59
4.2 测量方案 60
4.2.1 保持计算的有效性 61
4.2.2 比较和因果测量方案 62
4.2.3 状态类型:定义计划的和实际的状态 63
4.2.4 构造测量 66
4.2.5 维度合并 66
4.3 范围 69
4.4 带范围的现象 70
4.4.1 带范围属性的现象 71
4.4.2 范围函数 73
4.5 使用最终框架 75
第5章 引用对象 77
5.1 名称 77
5.2 标识方案 79
5.3 对象合并 81
5.3.1 复制并替换 82
5.3.2 替代 82
5.3.3 本质/表象 83
5.4 对象等价 83
第6章 库存与账务 85
6.1 账目 87
6.2 事务 88
6.3 汇总账目 90
6.4 备注账目 92
6.5 记入规则 93
6.5.1 可逆性 94
6.5.2 不使用事务 94
6.6 个体实例方法 95
6.6.1 使用singleton类实现 95
6.6.2 使用策略模式实现 96
6.6.3 使用内部case语句实现 97
6.6.4 使用参数化方法实现 98
6.6.5 使用解释器实现 98
6.6.6 实现方式的选择 99
6.7 记入规则的执行 99
6.7.1 急切触发 99
6.7.2 基于账目的触发 101
6.7.3 基于记入规则的触发 102
6.7.4 向后链式触发 102
6.7.5 触发手段的比较 102
6.8 多个账目的记入规则 103
6.9 选择条目 106
6.10 账务实践 107
6.11 条目来源 109
6.12 结算单和所得计算书 110
6.13 对应账目 111
6.14 专门化的账目模型 112
6.15 登记条目到多个账目 113
6.15.1 使用备注账目 116
6.15.2 派生账目 116
进一步阅读 118
第7章 使用财务模型 119
7.1 结构模型 120
7.2 结构的实现 122
7.3 设置新的电话服务 124
7.4 建立通话 126
7.5 实现基于账目的触发 127
7.6 把电话分成白天和夜晚两类 128
7.7 按时间收费 130
7.8 计算税款 133
7.9 结论 134
7.9.1 记入规则的结构 134
7.9.2 什么时候不能使用框架 136
7.9.3 账务实践图 137
第8章 计划 139
8.1 提议和执行的动作 140
8.2 完成和放弃的动作 141
8.3 挂起 142
8.4 计划 143
8.5 方案 146
8.6 资源分配 149
8.7 输出和启动函数 153
第9章 交易 156
9.1 合同 156
9.2 合同夹 160
9.3 报价 165
9.4 场景 168
第10章 派生合同 176
10.1 期货合同 177
10.2 期权 179
10.2.1 多头、空头、看涨和看跌:体现一种谋略的词汇 181
10.2.2 子类型化或者非子类型化 182
10.3 产品 184
10.4 子类型状态机 188
10.4.1 确保状态图的一致 190
10.4.2 一致性的使用问题 192
10.5 并行的应用和领域层次结构 194
10.5.1 应用外观的类型检查 195
10.5.2 给超类型一个包装性接口 196
10.5.3 使用一个运行时属性 196
10.5.4 使应用外观对领域模型可见 198
10.5.5 使用异常处理 199
第11章 交易包 201
11.1 对一个包的多重访问级别 201
11.2 相互可见性 205
11.3 包的子类型化 208
11.4 结论 209
第二部分 支持模式
第12章 信息系统的分层构架 213
12.1 两层构架 214
12.2 三层构架 215
12.3 表示层和应用逻辑层 218
12.3.1 表示层/应用逻辑层分离的优点 222
12.3.2 在客户/服务器环境中伸展外观 222
12.4 数据库交互 224
12.4.1 把领域层连接到数据源 224
12.4.2 数据库接口层 225
12.5 结论 227
第13章 应用外观 229
13.1 一个医疗保健示例 229
13.2 外观的内容 231
13.2.1 方法的类型 232
13.2.2 样本方法 233
13.3 公共方法 234
13.4 操作 235
13.5 类型转换 236
13.6 多重外观 237
第14章 类型模型的模式—设计模板 240
14.1 实现关联 242
14.1.1 双向关联和单向关联 243
14.1.2 关联的接口 243
14.1.3 基础类型 245
14.1.4 实现一个单向关联 246
14.1.5 在两个方向上都使用指针的双向实现 246
14.1.6 在一个方向上使用指针的双向实现 247
14.1.7 使用关联对象的双向实现 248
14.1.8 双向实现的比较 248
14.1.9 派生映射 249
14.1.10 非集合映射 249
14.2 实现泛化 249
14.2.1 用继承实现 249
14.2.2 用多重继承组合类实现 250
14.2.3 用标志实现 250
14.2.4 用委托给一个隐藏类来实现 251
14.2.5 通过创建一个替换来实现 253
14.2.6 泛化的接口 254
14.2.7 实现hasType操作 255
14.3 对象创建 255
14.3.1 创建的接口 256
14.3.2 创建的实现 256
14.4 对象析构 256
14.4.1 析构的接口 257
14.4.2 析构的实现 257
14.5 入口点 258
14.5.1 查找对象的接口 259
14.5.2 查找操作的实现 260
14.5.3 使用类或者登记表对象 260
14.6 实现约束 260
14.7 其它技术的设计模板 261
第15章 关联模式 263
15.1 关联类型 264
15.2 带键值的映射 266
15.3 历史映射 268
第16章 后记 273
第三部分 附 录
附录A 技术和符号 277
附录B 模式列表 293
索引 301


网络资源搜索:https://github.com/holbrook/mybooks/blob/master/1.analysis/%E5%88%86%E6%9E%90%E6%A8%A1%E5%BC%8F%E5%8F%AF%E5%A4%8D%E7%94%A8%E7%9A%84%E5%AF%B9%E8%B1%A1%E6%A8%A1%E5%9E%8B(%E4%B8%AD%E6%96%87%E7%89%88).pdf

软件过程模型-概述

软件工程–软件过程模型

软件过程是为了获得高质量软件所需要完成的一系列任务的框架,它规定了完成各项任务的工作步骤。通常使用生命周期模型简洁地描述软件过程。生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序,因此,也称为过程模型。常见的过程模型有瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型等。

1.瀑布模型

这个特点有两重含义:

1.必须等前一阶段的工作完成之后,才能开始后一阶段的工作;

2.前一阶段的输出文档就是后一阶段的输入文档,因此,只有前一阶段的输出文档正确,后一阶段的工作才能获得正确的结果。

瀑布模型每个阶段都应坚持两个重要做法:

1.每个阶段都必须完成规定的文档,没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档是软件开发时期各类人员之间相互通信的媒介,也是运行时期对软件进行维护的重要依据。

2.每个阶段结束前都要对所完成的文档进行评审,以便迟早发现问题,改正错误。事实上越是早期阶段犯下的错误,暴露出来的时间就越晚,排除故障改正错误所需付出的代价也越高。因此,及时审查,是保证软件质量,降低软件成本的重要措施。

可以说瀑布模型是由文档驱动的。这个事实也是它的一个缺点,在可运行的软件产品交付给用户之前,用户只能通过文档来了解产品是什么样的。瀑布模型历史悠久、广为人知的,它的优势在于它是规范的、文档驱动的方法;这种模型的问题是,最终开发出的产品可能并不是用户真正需要的。

(1)传统的瀑布模型:

 

(2)实际的瀑布模型:

 

2.快速原型模型

所谓快速原型是快速建立起来的可以在计算机上运行的程序,它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型的本质是“快速”,开发人员应该尽可能快地建造出原型系统,以加速软件开发过程,节约软件开发成本。原型的用作是获知用户的真正需求,一旦需求确定了,原型系统将被抛弃。

快速原型模型正是为了克服瀑布模型的缺点而提出来的。它通过快速构建一个可在计算机上运行的原型系统,让用户试用原型系统并收集用户反馈意见的办法,获取用户的真实需求。

 

3.增量模型

增量模型也称为渐增模型,使用增量模型开发软件时,把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成,并且能够完成特定的功能。使用增量模型时,第一个增量构件往往实现软件的基本需求,提供最核心的功能。

优点:

1.能在较短的时间内向用户提交可完成部分工作的产品。

2.逐步增加产品功能可以使用户有充裕的时间学习和适应新产品,从而减少一个全新的软件可能给客户组织带来的冲击。

增量模型具有可在软件开发的早期阶段使投资获得明显回报和较易维护的优点,但是,要求软件具有开放的结构是使用这种模型时固有的困难。

 

4.螺旋模型

螺旋模型的基本思想就是,使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法,是把它看作每个阶段之前都增加了风险分析过程的快速原型模型。

螺旋模型主要适用于内部开发的大规模软件项目。如果进行风险分析的费用接近整个项目的经费预算,则风险分析是不可行的。事实上项目越大,风险也越大,因此进行风险分析的必要性也越大。此外只有内部开发的项目,才能在风险过大时方便中止项目。

螺旋模型的主要优势在于,它是风险驱动,但是,这也可能是它的一个弱点。除非软件开发人员具有丰富的风险评估经验和这方面的专门知识,否则将出现真正的风:当项目实际上正在走向灾难时,开发人员可能还认为一切正常。

风险驱动的螺旋模型适用于内部开发的大型软件项目,但是,只有在开发人员具有风险分析和排除风险的经验及专门知识时,使用这种模型才会获得成功。

(1)简化的螺旋模型

 

(2)完整的螺旋模型

4.喷泉模型

喷泉模型对软件复用和生存周期中多项开发活动的集成提供了支持,以面向对象的软件开发方法为基础,它适合面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。系统某个部分常常重复工作多次,相关功能在每次迭代中随之加入演化的系统。无间隙是指在分析、设计和实现等开发活动之间不存在明显的边界。

 

按照在软件生命周期过程中应完成的任务的性质,在概念上可以把软件生命周期划分成定义、可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试以及运行维护等8个阶段。实际从事软件开发工作时,软件规模、种类、开发环境及使用的技术方法等因素,都影响各阶段的划分。

软件过程是为了获得高质量的软件产品所需要完成的一系列任务的框架,它规定了完成各项任务的工作步骤。由于没有适用所有软件项目的任务集合,科学、有效的软件过程应该定义一组适合所承担的项目特点的任务集合。通常使用软件过程模型简洁地描述软件过程,它规定了把软件生命周期划分成的阶段及各个阶段的顺序。

来自:http://www.cnblogs.com/houleixx/archive/2009/10/20/software-engineering-process-model.html

软件架构模式-附录A和关于作者

附录A

模式分析总结

图A-1 总结了在这个报告中,对于架构模式的每部分进行的模式分析所产生的影响。这个总结帮助你确定哪些模式可能是最适合你的情况。例如,如果你的架构模式重点是可伸缩性,你可以在这个图表看看事件驱动模式,microservices模式,和基于空间模式,这些对于你来说可能是很好的架构模式的选择。同样的,如果你的程序注重的是分层架构模式,你可以参考图看到部署、性能和可伸缩性的在你的架构中所存在的风险。

同时这个图表将指导你选择正确的模式,因为在选择一种架构模式的时候,有更多的因素需要考虑。你必须分析你的环境的各个方面,包括基础设施的支持,开发人员技能,项目预算,项目最后期限,和应用程序大小等等。选择正确的架构模式是至关重要的,因为一旦一个架构被确定就很难改变。

关于作者

Mark•Richards是一位有丰富经验的软件架构师,他参与架构、设计和实施microservices体系结构、面向服务的体系结构和在J2EE中的分布式系统和其他技术。自1983年以来,他一直从事软件行业,在应用、继承和企业架构方面有大量的经验和专业知识。

Mark在1999到2003年间担任新英格兰Java用户组的主席。他是许多技术书籍和视频的作者,包括软件架构基础(O‘Reilly视频)、企业消息传递(O’Reilly视频),《Java消息服务,第二版》(O’Reilly)和《软件架构师应该知道的97件事》(O’Reilly)的特约作者。Mark拥有一个计算机科学硕士学位并且多次获得IBM、Sun、开放集团和BEA等颁发的架构师和开发人员认证。

他是Fluff Just Stuff(NFJS)研讨会系列(一个不定期会议)议长,并且有过上百次的在世界各地公益会议和用户组上围绕技术主题的演讲经验)。Mark不工作的时候经常会到白色山脉或阿帕拉契山径徒步旅行。

软件架构模式-第五章 基于空间的架构

第五章 基于空间的架构


大多数基于网站的商务应用都遵循相同的请求流程:一个请求从浏览器发到web服务器,然后到应用服务器,然后到数据库服务器。虽然这个模式在用户数不大的时候工作良好,但随着用户负载的增加,瓶颈会开始出现,首先出现在web服务器层,然后应用服务器层,最后数据库服务器层。通常的解决办法就是向外扩展,也就是增加服务器数量。这个方法相对来说简单和廉价,并能够解决问题。然而,对于大多数高访问量的情况,它只不过是把web服务器的问题移到了应用服务器。而扩展应用服务器会更复杂,而且成本更高,并且又只是把问题移动到了数据库服务器,那会更复杂,更贵。就算你能扩展数据库服务器,你最终会陷入一个金字塔式的情形,在金字塔最下面是web服务器,它会出现最多的问题,但也最好伸缩。金字塔顶部是数据库服务器,问题不多,但最难伸缩。

在一个高并发大容量的应用中,数据库通常是决定应用能够支持多少用户同时在线的关键因素。虽然各种缓存技术和数据库伸缩产品都在帮助解决这个问题,但数据库难以伸缩的现实并没有改变。

基于空间的架构模型是专门为了解决伸缩性和并发问题而设计的。它对于用户数量不可预测且数量级经常变化的情况同样适用。在架构级别来解决这个伸缩性问题通常是比增加服务器数量或者提高缓存技术更好的解决办法。

模型介绍

基于空间的模型(有时也称为云架构模型)旨在减少限制应用伸缩的因素。模型的名字来源于分布式共享内存中的 tuple space(数组空间)概念。高伸缩性是通过去除中心数据库的限制,并使用从内存中复制的数据框架来获得的。保存在内存的应用数据被复制给所有运行的进程。进程可以动态的随着用户数量增减而启动或结束,以此来解决伸缩性问题。这样因为没有了中心数据库,数据库瓶颈就此解决,此后可以近乎无限制的扩展了。

大多数使用这个模型的应用都是标准的网站,它们接受来自浏览器的请求并进行相关操作。竞价拍卖网站是一个很好的例子 ( 12306更是一个典型的示例 )。网站不停的接受来自浏览器的报价。应用收到对某一商品的报价,记录下报价和时间,并且更新对该商品的报价,将信息返回给浏览器。

这个架构中有两个主要的模块:处理单元 和 虚拟化中间件。下图展示了这个架构和里面的主要模块。

处理单元包含了应用模块(或者部分的应用模块)。具体来说就是包含了web组件以及后台业务逻辑。处理单元的内容根据应用的类型而异——小型的web应用可能会部署到单一的处理单元,而大型一些的应用会将应用的不同功能模块部署到不同的处理单元中。典型的处理单元包括应用模块,以及保存在内存的数据框架和为应用失败时准备的异步数据持久化模块。它还包括复制引擎,使得虚拟化中间件可以将处理单元修改的数据复制到其他活动的处理单元。

虚拟化中间件负责保护自身以及通信。它包含用于数据同步和处理请求的模块,以及通信框架,数据框架,处理框架和部署管理器。这些在下文中即将介绍的部分,可以自定义编写或者购买第三方产品来实现。

组件间合作

基于空间的架构的魔力就在虚拟化中间件,以及各个处理单元中的内存中数据框架。下图展示了包含着应用模块、内存中数据框架、处理异步数据恢复的组件和复制引擎的处理单元架构。

虚拟化中间件本质上是架构的控制器,它管理请求,会话,数据复制,分布式的请求处理和处理单元的部署。虚拟化中间件有四个架构组件:通信框架,数据框架,处理框架和部署管理器。

通信框架

通信框架管理输入请求和会话信息。当有请求进入虚拟化中间件,通信框架就决定有哪个处理单元可用,并将请求传递给这个处理单元。通信框架的复杂程度可以从简单的round robin算法到更复杂的用于监控哪个请求正在被哪个处理单元处理的next-available算法。

数据框架

数据框架可能是这个架构中最重要和关键的组件。它与各个处理单元的数据复制引擎交互,在数据更新时来管理数据复制功能。由于通信框架可以将请求传递给任何可用的处理单元,所以每个处理单元包含完全一样的内存中数据就很关键。下图展示处理单元间如何同步数据复制,实际中是通过非常迅速的并行的异步复制来完成的,通常在微秒级。

处理框架

处理框架,就像下图所示,是虚拟化中间件中一个可选组件,负责管理在有多个处理单元时的分布式请求处理,每个处理单元可能只负责应用中的某个特定功能。如果请求需要处理单元间合作(比如,一个订单处理单元和顾客处理单元),此时处理框架就充当处理单元见数据传递的媒介。

部署管理器

部署管理器根据负载情况管理处理单元的动态启动和关闭。它持续检测请求所需时间和在线用户量,在负载增加时启动新的处理单元,在负载下降时关闭处理单元。它是实现可变伸缩性需求的关键。

其他考虑

基于空间的架构是一个复杂和实现起来相对昂贵的框架。对于有可变伸缩性需求的小型web应用是很好的选择,然而,对于拥有大量数据操作的传统大规模关系型数据库应用,并不那么适用。

虽然基于空间的架构模型不需要集中式的数据储存,但通常还是需要这样一个,来进行初始化内存中数据框架,和异步的更新各处理单元的数据。通常也会创建一个单独的分区,来从隔离常用的断电就消失的数据和不常用的数据,这样减少处理单元之间对对方内存数据的依赖。

值得注意的是,虽然这个架构的另一个名字是云架构,处理单元(以及虚拟化中间件)都没有放在云端服务或者PaaS上。他们同样可以简单的放在本地服务器,这也是为什么我更倾向叫它“基于空间的架构”。

从产品实现的角度讲,这个架构中的很多组件都可以从第三方获得,比如GemFire, JavaSpaces, GigaSpaces,IBM Object Grid,nCache,和 Oracle Coherence。由于架构的实现根据工程的预算和需求而异,所以作为架构师,你应该在实现或选购第三方产品前首先明确你的目标和需求。

架构分析

下面的表格是这个架构的特征分析和评分。每个特征的评分是基于一个典型的架构实现来给出的。要知道这个模式相对别的模式的对比,请参见最后的附录A。

综合能力

评分:高 分析:综合能力是对环境变化做出快速反应的能力。因为处理单元(应用的部署实例)可以快速的启动和关闭,整个应用可以根据用户量和负载做出反应。使用这个架构通常在应对代码变化上,由于较小的应用规模和组件间相互依赖,也会反映良好。

易于部署

评分:高 分析:虽然基于空间的架构通常没有解耦合并且功能分布,但他们是动态的,也是成熟的基于云的工具,允许应用轻松的部署到服务器。

可测试性

评分:低 分析:测试高用户负载既昂贵又耗时,所以在测试架构的可伸缩性方面很困难

性能

评分:高 分析:通过内存中数据存取和架构中的缓存机制可获得高性能

伸缩性

评分:高 分析:高伸缩性是源于几乎不依赖集中式的数据库,从而去除了这个限制伸缩性的瓶颈。

易于开发

评分:低 分析:主要是因为难以熟悉这个架构开发所需得工具和第三方产品,因此使用该架构需要较大的学习成本。而且,开发过程中还需要特别注意不要影响到性能和可伸缩性。

软件架构模式-第四章 微服务架构

第四章 微服务架构


微服务架构模式作为替代单体应用和面向服务架构的一个可行的选择,在业内迅速取得进展。由于这个架构模式仍然在不断的发展中,在业界存在很多困惑——这种模式是关于什么的?它是如何实现的?本报告的这部分将为你提供关键概念和必要的基础知识来理解这一重要架构模式的好处(和取舍),以此来判断这种架构是否适合你的应用。

模式描述

不管你选择哪种拓扑或实现风格,有几种常见的核心概念适用于一般架构模式。第一个概念是单独部署单元。如图4-1所示,微服务架构的每个组件都作为一个独立单元进行部署,让每个单元可以通过有效、简化的传输管道进行通信,同时它还有很强的扩展性,应用和组件之间高度解耦,使得部署更为简单。

也许要理解这种模式,最重要的概念就是服务组件(service component)。不要考虑微服务架构内部的服务,而最好是考虑服务组件,从粒度上讲它可以小到单一的模块,或者大至一个应用程序。服务组件包含一个或多个模块(如Java类),这些模块可以提供一个单一功能(如,为特定的城市或城镇提供天气情况),或也可以作为一个大型商业应用的一个独立部分(如,股票交易布局或测定汽车保险的费率)。在微服务架构中,正确设计服务组件的粒度是一个很大的挑战。在接下来的服务组件部分对这一挑战进行了详细的讨论。

微服务架构模式的另一个关键概念是它是一个分布式的架构,这意味着架构内部的所有组件之间是完全解耦的,并通过某种远程访问协议(如, JMS, AMQP, REST, SOAP, RMI等)进行访问。这种架构的分布式特性是它实现一些优越的可扩展性和部署特性的关键所在。

微服务架构另一个令人兴奋的特性是它是由其他常见架构模式存在的问题演化来的,而不是作为一个解决方案被创造出来等待问题出现。微服务架构的演化有两个主要来源:使用分层架构模式的单体应用和使用面向服务架构的分布式应用。

由单体应用( 一个应用就是一个整体 )到微服务的发展过程主要是由持续交付开发促成的。从开发到生产的持续部署管道概念,简化了应用程序的部署。单体应用通常是由紧耦合的组件组成,这些组件同时又是另一个单一可部署单元的一部分,这使得它繁琐,难以改变、测试和部署应用(因此常见的“月度部署”周期出现并通常发生在大型IT商店项目)。这些因素通常会导致应用变得脆弱以至于每次有一点新功能部署后应用就不能运行。微服务架构模式通过将应用分隔成多个可部署的单元(服务组件)的方法来解决这一问题,这些服务组件可以独立于其他服务组件进行单独开发、测试和部署。

另一个导致微服务架构模式产生的演化过程是由面向服务架构模式(SOA)应用程序存在的问题引起的。虽然SOA模式非常强大,提供了无与伦比的抽象级别、异构连接、服务编排,并保证通过IT能力调整业务目标,但它仍然是复杂的,昂贵的,普遍存在,它很难理解和实现,对大多数应用程序来说过犹不及。微服务架构通过简化服务概念,消除编排需求、简化服务组件连接和访问来解决复杂度问题。

模式拓扑

虽然有很多方法来实现微服务架构模式,但三个主要的拓扑结构脱颖而出,最常见和流行的有:基于REST API的拓扑结构,基于REST的应用拓扑结构和集中式消息拓扑结构。

基于REST的API拓扑适用于网站,通过某些API对外提供小型的、自包含的服务。这种拓扑结构,如图4 – 2所示,由粒度非常细的服务组件(因此得名微服务)组成,这些服务组件包含一个或两个模块并独立于其他服务来执行特定业务功能。在这种拓结构扑中,这些细粒度的服务组件通常被REST-based的接口访问,而这个接口是通过一个单独部署的web API层实现的。此种拓扑的例子包含一些常见的专用的、基于云的RESTful web service,大型网站像Yahoo, Google, and Amazon都在使用。

基于REST的应用拓扑结构与基于REST API的不同,它通过传统的基于web的或胖客户端业务应用来接收客户端请求,而不是通过一个简单的API层。如图4-3所示,应用的用户接口层(user interface layer)是一个web应用,可以通过简单的REST-based接口访问单独部署的服务组件(业务功能)。该拓扑结构中的服务组件与API-REST-based拓扑结构中的不同,这些服务组件往往会更大、粒度更粗、代表整个业务应用程序的一小部分,而不是细粒度的、单一操作的服务。这种拓扑结构常见于中小型企业等复程度相对较低的应用程序。

微服务架构模式中另一个常见的方法是集中式消息拓扑。该拓扑(如图4-4所示)与前面提到的基于REST的应用拓扑类似,不同的是,application REST- based拓扑结构使用REST进行远程访问,而该拓扑结构则使用一个轻量级的集中式消息代理(如,ActiveMQ, HornetQ等等)。不要将该拓扑与面向服务架构模式混淆或将其当做SOA简化版(“SOA-Lite”),这点是极其重要的。该拓扑中的轻量级消息代理(Lightweight Message Broker)不执行任何编排,转换,或复杂的路由;相反,它只是一个轻量级访问远程服务组件的传输工具。

集中式消息拓扑结构通常应用在较大的业务应用程序中,或对于某些对传输层到用户接口层或者到服务组件层有较复杂的控制逻辑的应用程序中。该拓扑较之先前讨论的简单基于REST的拓扑结构,其好处是有先进的排队机制、异步消息传递、监控、错误处理和更好的负载均衡和可扩展性。与集中式代理相关的单点故障和架构瓶颈问题已通过代理集群和代理联盟(将一个代理实例为分多个代理实例,把基于系统功能区域的吞吐量负载划分开处理)解决。

避免依赖和编排

微服务架构模式的主要挑战之一就是决定服务组件的粒度级别。如果服务组件粒度过粗,那你可能不会意识到这个架构模式带来的好处(部署、可扩展性、可测试性和松耦合),然而,服务组件粒度过细将导致服务编制要求,这会很快导致将微服务架构模式变成一个复杂、容易混淆、代价昂贵并易于出错的重量级面向服务架构。

如果你发现需要从应用内部的用户接口或API层编排服务组件,那么很有可能你服务组件的粒度太细了。如果你发现你需要在服务组件之间执行服务间通信来处理单个请求,那么很有可能要么是你服务组件的粒度太细了,要么是没有从业务功能角度正确划分服务组件。

服务间通信,可能导致组件之间产生耦合,但可以通过共享数据库进行处理。例如,若一个服务组件处理网络订单而需要用户信息时,它可以去数据库检索必要的数据,而不是调用客户服务组件的功能。

共享数据库可以处理信息需求,但是共享功能呢?如果一个服务组件需要的功能包含在另一个服务组件内,或是一个公共的功能,那么有时你可以将服务组件的共享功能复制一份(因此违反了DRY规则:don’t repeat yourself)。为了保持服务组件独立和部署分离,微服务架构模式实现中会存在一小部分由重复的业务逻辑而造成的冗余,这在大多数业务应用程序中是一个相当常见的问题。小工具类可能属于这一类重复的代码。

如果你发现就算不考虑服务组件粒度的级别,你仍不能避免服务组件编排,这是一个好迹象,可能此架构模式不适用于你的应用。由于这种模式的分布式特性,很难维护服务组件之间的单一工作事务单元。这种做法需要某种事务补偿框架回滚事务,这对此相对简单而优雅的架构模式来说,显著增加了复杂性。

注意事项

微服务架构模式解决了很多单体应用和面向服务架构应用存在的问题。由于主要应用组件被分成更小的,单独部署单元,使用微服务架构模式构建的应用程序通常更健壮,并提供更好的可扩展性,支持持续交付也更容易。

该模式的另一个优点是,它提供了实时生产部署能力,从而大大减少了传统的月度或周末“大爆炸”生产部署的需求。因为变化通常被隔离成特定的服务组件,只有变化的服务组件才需要部署。如果你的服务组件只有一个实例,你可以在用户界面程序编写专门的代码用于检测一个活跃的热部署,一旦检测到就将用户重定向到一个错误页面或等待页面。你也可以在实时部署期间,将服务组件的多个实例进行交换,允许应用程序在部署期间保持持续可用性(分层架构模式很难做到这点)。

最后一个要重视的考虑是,由于微服务架构模式是分布式的架构,他与事件驱动架构模式具有一些共同的复杂的问题,包括约定的创建、维护,和管理,远程系统的可用性,远程访问身份验证和授权。

模式分析

下面这个表中包含了微服务架构模式的特点分析和评级,每个特性的评级是基于自然趋势,基于典型模式实现的能力特性,以及该模式是以什么闻名的。本报告中该模式与其他模式的并排比较,请参考报告最后的附件A。

整体灵活性

评级:高 分析:整体的灵活性是能够快速响应不断变化的环境。由于单独部署单元的概念,变化通常被隔离成单独的服务组件,使得部署变得快而简单。同时,使用这种模式构建的应用往往是松耦合的,也有助于促进改变。

易于部署

评级:高 分析:整体来讲,由于该模式的解耦特性和事件处理组件使得部署变得相对简单。broker拓扑往往比mediator拓扑更易于部署,主要是因为event-mediator组件与事件处理器是紧耦合的,事件处理器组件有一个变化可能导致event mediator跟着变化,有任何变化两者都需要部署。

可测试性

评级:高 分析:由于业务功能被分离成独立的应用模块,可以在局部范围内进行测试,这样测试工作就更有针对性。对一个特定的服务组件进行回归测试比对整个单体应用程序进行回归测试更简单、更可行。而且,由于这种模式的服务组件是松散耦合的,从开发角度来看,由一个变化导致应用其他部分也跟着变化的几率很小,并能减小由于一个微小的变化而不得不对整个应用程序进行测试的负担。

性能

评级:低 分析:虽然你可以从实现该模式来创建应用程序并可以很好的运行,整体来说,由于微服务架构模式的分布式特性,并不适用于高性能的应用程序。

伸缩性

评级:高 分析:由于应用程序被分为单独的部署单元,每个服务组件可以单独扩展,并允许对应用程序进行扩展调整。例如,股票交易的管理员功能区域可能不需要扩展,因为使用该功能的用户很少,但是交易布局服务组件可能需要扩展,因为大多数交易应用程序需要具备处理高吞吐量的功能。

易于开发

评级:高 分析:由于功能被分隔成不同的服务组件,由于开发范围更小且被隔离,开发变得更简单。程序员在一个服务组件做出一个变化影响其他服务组件的几率是很小的,从而减少开发人员或开发团队之间的协调。

软件架构模式-第三章 微内核架构

第三章 微内核架构


微内核架构模式(也称为插件化应用架构)对于基于产品的应用程序来说是一个很自然的选择。基于产品的应用是指一个经过打包的、可以通过版本下载的一个典型的第三方产品。然而,很多公司也会开发和发布他们的内部商业软件,完整的版本号、发布日志和可插拔的新特性,这些就非常符合微内核架构的思想。微内核架构模式可以通过插件的形式添加额外的特性到核心系统中,这提供了很好的扩展性,也使得新特性与核心系统隔离开来。( 译者注: 比如,著名的Eclipse IDE就是基于插件化开发的,eclipse核心更像是一个微内核,或者我们可把它叫做开放平台,其他的功能通过安装插件的形式添加到eclipse中。 )

模式描述

微内核架构主要需要考虑两个方面: 核心系统和插件模块。应用逻辑被划分为独立的插件模块和核心系统,这样就提供良好的可扩展性、灵活性,应用的新特性和自定义处理逻辑也会被隔离。图3-1演示了基本的微内核架构。

微内核架构的核心系统一般情况下只包含一个能够使系统运作起来的最小化模块。很多操作系统的实现就是使用微内核架构,因此这也是该架构名字的由来。从商业应用的角度看,核心系统通常是为特定的使用场景、规则、或者复杂条件处理定义了通用的业务逻辑,而插件模块根据这些规则实现了具体的业务逻辑。

插件模块是一个包含专业处理、额外特性的独立组件,自定义代码意味着增加或者扩展核心系统以达到产生附加的业务逻辑的能力。通常,插件模块之间应该是没有任何依赖性的,但是你也可以设计一个需要依赖另一个插件的插件。但无论如何,使得插件之间可以通信的同时避免插件之间产生依赖又是一个特别重要的问题。

核心系统需要了解插件模块的可用性以及如何获取到它们。一个通用的实现方法是通过一组插件注册表。这个插件注册表含有每个插件模块的信息,包括它的名字、数据规约和远程访问协议(取决于插件如何与核心系统建立连接)。例如,一个税务软件的用于标识高风险的税务审计插件可能会有一个含有插件名(比如AuditChecker)的注册入口,数据规约(输入数据、输出数据)和规约格式( 比如xml )。如果这个插件是通过SOAP服务访问,那么它可能会包含一个WSDL (Web Services Definition Language).

插件模块可以通过多种方式连接到核心系统,包括OSGi ( open service gateway initiative )、消息机制、web服务或者直接点对点的绑定 ( 比如对象实例化,即依赖注入 )。你使用的连接类型取决于你构建的应用类型和你的特殊需求(比如单机部署还是分布式部署)。微内核架构本身没有指定任何的实现方式,唯一的规定就是插件模块之间不要产生依赖。

插件和核心系统的通信规范包含标准规范和自定义规范。自定义规范典型的使用场景是插件组件是被第三方构建的。在这种情况下,通常是在第三方插件规约和你的标准规范创建一个Adapter来使核心系统根本不需要知道每个插件的具体细节。当创建标准规范 ( 通常是通过XML或者Java Map )时,从一开始就创建一个版本策略是非常重要的。

架构示例

也许微内核架构的最好示例就是大家熟知的Eclipse IDE了。下载最基本的Eclipse后,它只能提供一个编辑器。然后,一旦你开始添加插件,它就变成一个高度可定制化和非常有用的产品(译者注 : 更多内容大家可以参考 开源软件架构 卷1:第6章 Eclipse之一 )。浏览器是另一个使用微内核架构的产品示例,它由一个查看器和其他扩展的插件组成。

基于微内核架构的示例数不胜数,但是大型的商业应用呢?微内核应用架构也适用于这些情形。为了阐述这个观点,让我们来看看另一个保险公司的示例,但是这次的示例会涉及保险赔偿处理。

赔偿处理是一个非常复杂的过程。每个州都有不同的关于保险赔偿的规则和条文。例如一些州允许在你的挡风玻璃被石头砸碎时免费进行替换,但是一些州则不是这样。因为大家的标准都不一样,因此赔偿标准几乎可以是无限的。

有很多保险赔偿应用运用大型和复杂的规则处理引擎来处理不同规则带来的复杂性。然而,可能会因为某条规则的改变而引起其他规则的改变而使得这些规则处理引擎变成一个大泥球,或者使简单需求变更会需要一个很大的分析师、工程师、测试工程师来进行处理。使用微内核架构能够很好的解决这个问题,核心系统只知道根据赔偿规则处理,但这个赔偿规则是抽象的,系统将赔偿规则作为一个插件规范,具体的规则有对应的实现,然后注入到系统中即可。

图3-2中的一堆文件夹代表了赔偿处理核心系统。它包含一些处理保险赔偿的基本业务逻辑。每一个插件模块包含每个州的具体赔偿规则。在这个例子中,插件模块通过自定义源代码实现或者分离规则引起实例。不管具体实现如何,关键就在于赔偿规则和处理都从核心系统中分离,而这些规则和处理过程都可以被动态地添加、移除,而这些改变对于核心系统和其他插件只有很小的影响或者根本不产生影响。

注意事项

对于微内核架构来说一个很重要的一点就是它能够被嵌入或者说作为另一种架构的一部分。例如,如果这个架构解决的是一个你应用中易变领域的特定的问题 ( 译者注 : 即插件化能够解决你应用中的某个特定模块的架构问题 ),你可能会发现你不能在整个应用中使用这种架构。在这种情况下,你可以将微内核架构嵌入到另一个架构模式中 ( 比如分层架构 )。同样的,在上一章节中描述的事件驱动架构中的事件处理器组件也可以使用微内核架构。

微内核架构对渐进式设计和增量开发提供了非常好的支持。你可以先构建一个单纯的核心系统,随着应用的演进,系统会逐渐添加越来越多的特性和功能,而这并不会引起核心系统的重大变化。

对基于产品的应用来说,微内核架构应该是你的第一选择。特别是那些你会在后续开发中发布附加特性和控制哪些用户能够获取哪些特性的应用。如果你在后续开发中发现这个架构不能满足你的需求了,你能够根据你的特殊需求将你的应用重构为另一个更好的架构。

模式分析

下面的表格中包含了微内核架构每个特性的评级和分析。以微内核架构的最经典的实现方式的自然趋势为依据对每个特性进行评级。关于微内核架构与其他模式的相关性比较请参考附录A。

整体灵活性

评级 : 高 分析 : 整体灵活性是指能够快速适应不断变化的环境的能力。通过插件模块的松耦合实现,可以将变化隔离起来,并且快速满足需求。通常,微内核架构的核心系统很快趋于稳定,这样系统就变得很健壮,随着时间的推移它也不会发生多大改变。

易于部署

评级 : 高 分析 : 根据实现方式,插件模块能够在运行时被动态地添加到核心系统中 ( 比如,热部署 ),把停机时间减到最小。

可测试性

评级 : 高 分析 : 插件模块能够被独立的测试,能够非常简单地被核心系统模拟出来进行演示,或者在对核心系统很小影响甚至没有影响的情况下对一个特定的特性进行原型展示。

性能

评级 : 高 分析 : 使用微内核架构不会自然而然地使你的应用变得高性能。通常,很多使用微内核架构的应用运行得很好,因为你能定制和简化应用程序,使它只包含那些你需要的功能模块。JBoss应用服务器就是这方面的优秀示例: 依赖于它的插件化架构,你可以只加载你需要的功能模块,移除那些消耗资源但没有使用的功能特性,比如远程访问,消息传递,消耗内存、CPU的缓存,以及线程,从而减小应用服务器的资源消耗。

伸缩性

评级 : 低 分析 : 因为微内核架构的实现是基于产品的,它通常都比较小。它们以独立单元的形式实现,因此没有太高的伸缩性。此时,伸缩性就取决于你的插件模块,有时你可以在插件级别上提供可伸缩性,但是总的来说这个架构并不是以构建高度伸缩性的应用而著称的。

易于开发

评级 : 低 分析 : 微内核架构需要考虑设计和规约管理,使它不会很难实现。规约的版本控制,内部的插件注册,插件粒度,丰富的插件连接的方式等是涉及到这个架构模式实现复杂度的重要因素。

软件架构模式-第二章 事件驱动架构

第二章 事件驱动架构


译者注:文章中 mediator 及 broker 的概念很容易混淆,在文章的结尾处译者对两者的区别(还有 proxy)进行了一定的阐述

事件驱动架构模式是一种主流的异步分发事件架构模式,常用于设计高度可拓展的应用。当然了,它有很高的适应性,使得它在小型应用、大型应用、复杂应用中都能表现得很好。事件驱动架构模式由高度解耦、单一目的的事件处理组件构成,这些组件负责异步接收和处理事件。

事件驱动架构模式包含了两种主要的拓扑结构:中介(mediator)拓扑结构和代理(broker)拓扑结构。 mediator 拓扑结构通常在你需要在事件内使用一个核心中介分配、协调多个步骤间的关系、执行顺序时使用;而代理拓扑结构则在你想要不通过一个核心中介将多个事件串联在一起时使用。由于这两种结构在结构特征和实现策略上有很大的差别,所以如果你想要在你的应用中使用它们的话,一定要深入理解两者的技术实现细节,从而为你的实际使用场景选择最合理的结构。

中介 ( Mediator )拓扑结构

中介拓扑结构适合用于拥有多个步骤,并需要在处理事件时能通过某种程度的协调将事件分层的场景,举例来说吧:假设你现在需要进行股票交易,那你首先需要证券所批准你进行交易,然后检查进行这次交易是否违反了股票交易的某种规定,检查完成后将它交给一个经纪人,计算佣金,最后与经纪人确认交易。以上所有步骤都需要通过中介进行某种程度的分配和协调,以决定各个步骤的执行顺序,判断哪些步骤可以并行,哪些步骤可以串行。

在中介拓扑结构中主要有四种组件:事件队列(event queue), 事件中介, 事件通道(event channel), 和 事件处理器(event processor)。当事件流需要被处理,客户端将一个事件发送到某个事件队列中,由消息队列将其运输给事件中介进行处理和分发。事件中介接收到该消息后,并通过将额外的异步事件发送给事件通道,让事件通道执行该异步事件中的每一个步骤,使得事件中介能够对事件进行分配、协调。同时,又因为事件处理器是事件通道的监听器,所以事件通道对异步事件的处理会触发事件处理器的监听事件,使事件处理器能够接收来自事件中介的事件,执行事件中具体的业务逻辑,从而完成对传入事件的处理。事件驱动架构模式中的中介拓扑模式结构大体如下图:

在事件驱动架构中拥有十几个,甚至几百个事件队列是很常见的情况,该模式并没有对事件队列的实现有明确的要求,这就意味着事件队列可以是消息队列,Web 服务端,或者其它类似的东西。

在事件驱动架构模式中主要有两种事件:初始事件和待处理事件。初始事件是中介所接收到的最原始的事件,没有经过其他组件的处理;而待处理事件是由事件中介生成,由事件处理器接收的组件,不能把待处理事件看作初始事件经过处理后得到的事件,两者是完全不同的概念。

事件中介负责分配、协调初始事件中的各个待执行步骤,事件中介需要为每一个初始事件中的步骤发送一个特定的待处理事件到事件通道中,触发事件处理器接收和处理该待处理事件。这里需要注意的是:事件 中介没有真正参与到对初始事件必须处理的业务逻辑的实现之中;相反,事件中介只是知道初始事件中有哪些步骤需要被处理。

事件中介通过事件通道将与初始事件每一个执行步骤相关联的特定待处理事件传递给事件处理器。尽管我们通常在待处理事件能被多个事件处理器处理时才会在中介拓扑结构中使用 消息主题,但事件通道仍可以是消息队列或 消息主题。(但需要注意的是,尽管在使用 消息主题 时待处理事件能被多个事件处理器处理,但由于接收到的待处理事件各异,所以对其处理的操作也各不相同)

为了能顺利处理待处理事件,事件处理器组件中包含了应用的业务逻辑。此外,事件处理器作为事件驱动架构中的组件,不依赖于其他组件,独立运作,高度解耦,在应用或系统中完成特定的任务。当事件处理器需要处理的事件从细粒度(例如:计算订单的营业税)变为粗粒度(例如:处理一项保险索赔事务),必须要注意的是:一般来说,每一个事件处理器组件都只完成一项唯一的业务工作,并且事件处理器在完成其特定的业务工作时不能依赖其他事件处理器。

虽然事件中介有许多方法可以实现,但作为一名架构工程师,你应该了解所有实现方式,以确保你能为你的实际需求选择了最合适的事件中介。

事件中介最简单、常见的实现就是使用开源框架,例如:Spring Integration,Apache Camel,或 Mule ESB。事件流在这些开源框架中通常用 Java 或 域特定语言(domain-specific language)。在调节过程和业务流程都很复杂的使用场景下,你可以使用业务流程执行语言(BPEL – business process execution language)结合类似开源框架 Apache ODE 的 BPEL 引擎进行开发。BPEL 是一种基于 XML 的服务编制编程语言,它为处理初始事件时需要描述的数据和步骤提供了描述。对每一个拥有复杂业务流程(包括与用户交互的执行步骤)的大型应用来说,你可以使用类似 jBPM 的业务处理管理系统(business process manager)实现事件中介。

如果你需要使用中介拓扑结构,那么理解你的需求,并为其匹配恰当的事件中介实现是构建事件驱动架构过程中至关重要的一环。使用开源框架去解决非常复杂的业务处理、管理、调节事件,注定会失败,因为开源框架只是用 BPM 的方式解决了一些简单的事件分发逻辑,比起你的业务逻辑,其中的事件分发逻辑简直是九牛一毛。

为了解释清楚中介拓扑结构是怎么运作的,我假设你在某家保险公司买了保险,成为了受保人,然后你打算搬家。在这种情况下,初始事件就是重定位事件,或者其他类似的事件。与重定位事件相关的处理步骤就像下图展示的那样,处于事件中介之中。对每一个初始事件的传入,事件中介都会创建一个待处理事件(例如:改变地址,重新计算保险报价,等等……),并将它发送给事件通道,等待发出响应的事件处理器处理待处理事件(例如:客户改变地址的操作流程、报价计算流程,等等……)。直到初始事件中的每一个需要处理的步骤完成了,这项处理才会继续(例如:把所有手续都完成之后,保险公司才会帮你改变地址)。事件中介中,重新报价和更新理赔步骤上面的直线表示这些步骤可以并行处理。

代理 (Broker) 拓扑结构

代理拓扑结构与中介拓扑结构不同之处在于:代理拓扑结构中没有核心的事件中介;相反,事件流在代理拓扑结构中通过一个轻量的消息代理(例如:ActiveMQ, HornetQ,等等……)将消息串联成链状,分发至事件处理器组件中进行处理。代理扑结构适用的使用场景大致上具有以下特征:你的事件处理流相对来说比较简单,而且你不想(不需要)使用核心的事件分配、调节机制以提高你处理事件的效率。

在代理拓扑结构中主要包括两种组件:代理和事件处理器。代理可被集中或相互关联在一起使用,此外,代理中还可以包含所有事件流中使用的事件通道。

存在于代理组件中的事件通道可以是消息队列,消息主题,或者是两者的组合。

代理拓扑结构大致如下图,如你所见,在这其中没有一个核心的事件中介组件控制和分发初始事件;相反,每一个事件处理器只负责处理一个事件,并向外发送一个事件,以标明其刚刚执行的动作。例如,假设存在一个事件处理器用于平衡证券交易,那么事件处理器可能会接受一个拆分股票的初始事件,为了处理这项初始事件,事件处理器则需要重新平衡股票的投资金额,而这个重新平衡的事件将由另一个事件处理器接收、处理。在这其中有一个细节需要注意:处理初始事件后,由事件处理器发出的事件不被其他事件处理器接收、处理的情况时常会发生,尤其是你在为应用添加功能和进行功能拓展时,这种情况更为常见。

为了阐明代理拓扑结构的运行机制,我会用一个与讲解中介拓扑结构时类似的例子(受保人旅行的例子)进行解释。因为在代理拓扑结构中没有核心事件中介接收初始事件,那么事件将由客户处理组件直接接收,改变客户的地址,并发出一个事件告知系统客户的地址被其进行了改变(例如:改变地址的事件)。在这个例子中:有两个事件处理器会与改变地址的事件产生关联:报价处理和索赔处理。报价事件处理器将根据受保人的新地址重新计算保险的金额,并发出事件告知系统该受保人的保险金额被其改变。而索赔事件处理器将接受到相同的改变地址事件,不同的是,它将更新保险的赔偿金额,并发出一个更新索赔金额事件告知系统该受保人的赔偿金额被其改变。当这些新的事件被其他事件处理器接收、处理,使事件链一环扣一环地交由系统处理,直到事件链上的所有事件都被处理完,初始事件的处理才算完成。

如上图所示,代理拓扑结构的设计思想就是将对事件流的处理转换为对事件链的业务功能处理,把代理拓扑结构看作是接力比赛是最好的理解方式:在一场4*100的接力比赛中,每一位运动员都需要拿着一根接力棒跑100米,运动员跑完自己的100米后需要将接力棒传递给下一位运动员,直到最后一位运动员拿着接力棒跑过终点线,整场接力比赛才算结束。根据这样的逻辑我们还可以知道:在代理拓扑结构中,一旦某个事件处理器将事件传递给另一个事件处理器,那么这个事件处理器不会与该事件的后续处理产生任何联系。

顾虑

实现事件驱动架构模式相对于实现其他架构模式会更困难一些,因为它通过异步处理进行事件分发。当你需要在你的应用中使用这种架构模式,你必须处理各种由事件分发处理带来的问题,例如:远程操作功能的可用性,缺少权限,以及在代理或中介中处理事件失败时,用于处理这种情况的重连逻辑。如果你不能很好地解决这些问题,那你的应用一定会出现各种 Bug,让开发团队痛苦不已。

在选择事件驱动架构时还有一点需要注意:在处理单个业务逻辑时,这种架构模式不能处理细粒度的事务。因为事件处理器都高度解耦、并且广泛分布,这使得在这些事件处理器中维持一个业务单元变得非常困难。因此,当你使用这种架构模式架构你的应用时,你必须不断地考虑哪些事件能单独被处理,哪些不能,并为此设计相应事件处理器的处理粒度。如果你发现你需要将一个业务单元切割成许多子单元,并一一匹配相应的事件处理器,那你就要为此进行代码设计;如果你发现你用多个不同的事件处理器处理的哪些业务其实是可以合并到一个业务事件之中的,那么这种模式可能并不适合你的应用,又或者是你的设计出了问题。

使用事件驱动架构模式最困难的地方就在于架构的创建、维护、以及对事件处理器的管理。通常每一个事件都拥有其指定的事件处理协议(例如:传递给事件处理器的数据类型、数据格式),这就使得设下标准的数据格式成为使用事件驱动架构模式中至关重要的一环(例如:XML,JSON,Java 对象,等等……),并在架构创建之初就为这些数据格式授权,以便处理。

模式分析

下面是基于对常见的架构模式特征进行评价的标准,对事件驱动架构模式所作的实际分析,评价是以常见的架构模式的相似实现作为标准进行的,如果你想知道进行对比的其他架构模式对应的特征,可以结尾处查看 附录A 的汇总表。

整体灵活性

评价:高 分析:整体灵活性用于评价架构能否在不断改变的使用场景下快速响应,因为事件处理器组件使用目的单一、高度解耦、与其他事件处理器组件相互独立,不相关联,那么发生的改变对一个或多个事件处理器来说普遍都是独立的,使得对改变的反馈非常迅速,不需要依赖其他事件处理器的响应作出处理。

易于部署

评价:高 分析:总的来看,事件驱动架构模式由于其高度解耦的事件处理器组件的存在,对事件的部署相对来说比较容易,而使用代理拓扑结构比使用中介拓扑结构进行事件调度会更容易一些,主要是因为在 中介拓扑结构中事件处理器与事件中介紧密地耦合在一起:事件处理器中发生改变后,事件中介也随之改变,如果我们需要改变某个被处理的事件,那么我们需要同时调度事件处理器和事件中介。

可测试性

评价:低 分析:虽然在事件驱动架构模式中进行单元测试并不困难,但如果我们要进行单元测试,我们就需要某种特定的测试客户端或者是测试工具产生事件,为单元测试提供初始值。此外,由于事件驱动架构模式是异步进行事件分发的,其异步处理的特性也为单元测试带来了一定的困难。

Performance 性能

评价:高 分析:对消息传递的架构可能会让设计出来的事件驱动架构的表现不如我们的期望,但通常来说,该模式都能通过其异步处理的特性展示优秀的性能表现;换句话来说,高度解耦,异步并行操作大大减少了传递消息过程中带来的时间开销。

伸缩性

评价:高 分析:事件驱动架构中的高度解耦、相互独立的事件处理器组件的存在,使得可拓展性成为该架构与生俱来的优点。架构的这些特定使得事件处理器能够进行细粒度的拓展,使得每一个事件处理器都能单独被拓展,而不影响其他事件处理器。

易于开发

评价:低 分析:由于使用事件驱动架构进行开发需要考虑其异步处理机制、协议创建流程,并且开发者需要用代码为事件处理器和操作失败的代理提供优秀的错误控制环境,无疑使得用事件驱动架构进行开发会比使用其他架构进行开发要困难一些。

译者注

读完整篇文章,我相信大家对 mediator 与 broker 这两个概念有一个大致的印象,但就两者的译文来看,中介和代理似乎没什么区别,尤其是了解 proxy 的读者会更加困惑,这三者之间到底是什么关系?它们的概念是互通的吗?为了解决这种混淆,译者将在此阐述三者间的区别:

假如现在我有一个事件/事件流需要被处理,那么使用 mediator、broker、proxy 处理事件的区别在哪里呢?

  • 如果我们使用 mediator,那就意味着我将把事件流交给 mediator,mediator 会帮我把事件分解为多个步骤,并分析其中的执行逻辑,调整和分发事件(例如判断哪些事件可以并行,哪些事件可以串行),然后根据 mediator 分解、调节的结果去执行事件中的每一个步骤,把所有步骤完成后,就能把需要处理的事件处理好。
  • 如果我们使用 broker,那就意味着我将把事件交给 broker,broker 获得事件后会把事件发出去(在本文中为:通知架构中所有可用的事件处理器),事件处理器们接收到事件以后,判断处理这个事件是否为自己的职责之一,如果不是则无视,与自己有关则把需要完成的工作完成,完成后如果事件还有后续需要处理的事件,则通过 broker 再次发布,再由相关的事件处理器接收、处理。以这样的方式将事件不断分解,沿着事件链一级一级地向下处理子事件,直到事件链中的所有事件被完成,我的事件也就处理好了。
  • 如果我们使用 proxy,那就意味着我自己对需要处理的事件进行了分解,然后把不同的子事件一一委托给不同的 proxy,由被委托的 proxy 帮我完成子事件,从而完成我要做的事件。