加载中…
个人资料
人月神话
人月神话 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:3,929,600
  • 关注人气:5,850
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
搜博主文章
主题阅读

企业架构-IT规划和咨询

企业架构 IT规划

云计算-私有云PaaS

平台 服务 组件 能力

人月神话-博客电子书下载

一次下载 离线阅读

人月神话-读书笔记

经典巨作 细细品味

规划咨询-IT规划

IT规划 咨询

人在职场-职业经理人自我修炼

格物 致知 诚意 正心

产品管理-组合管理

战略决策 组合分析

项目管理-PMBOK和PMP考试

九大知识体系 PMP

项目管理-质量管理

质量免费 6Sigma数据驱动

项目管理-方法工具技术

工欲善其事 必先利其器

项目管理-五大过程组

PDCA 全生命周期

项目实践-项目感悟

大道至简 无为而为

项目实践-敏捷软件开发

精益求精 简单执行

项目实践-在生活中学习

道在生活中 道在蝼蚁间

项目实践-进度游戏

目标驱动 迭代进度

个人技能-PPT制作和呈现

大道至简 道法自然

自我管理-人生感悟

物有所不足 智有所不明

自我管理-问题和思维

彼此独立 互无遗漏

自我管理-个人知识管理

为学日益 为道日损

诸法无我-学佛点滴

云水禅心 自性自渡

友情链接

修泽的Blog

成长-产品经理

周国平老师

人文-心灵导师

筱然的Blog

生活-心灵导师

胡因梦的Blog

禅修-心灵导师

傅佩荣的Blog

国学-心灵导师

萧秋水

上善若水-知性感性

栖息谷

我的家园

时光网

电影 社区

沃顿知识在线

咨询/知识/管理/经济

张恂的主页

软件工程思想

价值中国

管理商业财经投资

企业工程论坛

企业架构/建模

博文
标签:

devops

微服务

分类: IT咨询
今天基于实际的持续交付场景来谈下DevOps实践过程中的一些思考。

微服务模块划分

在微服务模块划分清楚后,各个微服务模块划分到不同的团队和人负责,那么每个团队对于自己负责的模块,在配置管理库和代码管理,数据库,开发项目上完全独立一套。负责A模块的团队不应该,也完全没有必要看到B模块开发的代码,而只需要关心接口即可。

微服务模块划分清楚后,实际上有个重点工作就是前期的架构设计和接口设计,需要先把各个微服务模块间的交互接口初步定下来,这个总体设计完成后再开始各个微服务模块的并行开发。而不是在开发中,想到需要什么接口就临时开发,这样很容易导致后续的接口混乱。

环境准备和微服务模块的开发

独立的项目,独立的代码管理,独立的数据库,但是不同的团队是基于相同的微服务开发框架,类似SpringCloud或其他开发框架进行微服务模块的开发。

A模块要调用B模块的接口才能够完成相应功能的开发和验证,这个时候就需要B模块提前准备好可用的接口并部署,
阅读  ┆ 转载 ┆ 收藏 
标签:

soa

devops

微服务

容器

杂谈

分类: IT咨询
在上篇文章,主要对DevOps的一些关键概念做了进一步解释和说明。对于DevOps实践,今天主要对一些零散的点做记录,在年后准备对基于我们的DevOps支撑平台进行DevOps实践写一系列的文章。

该系列文章具体的内容预计会包括:

1. 传统软件过程和单体技术架构存在的问题和需求分析
2. DevOps支撑平台的搭建和总体架构
3. DevOps支撑平台涉及到的工具集集成
4. DevOps实现端到端流水线作业和持续交付过程
5. DevOps与容器技术集成实现自动化部署和环境迁移能力
6. 基于DevOps的度量分析和最佳实践
7. DevOps平台和微服务开发框架的集成
8. DevOps平台和PaaS平台技术服务组件和技术服务能力的集成和最佳实践
9. 基于DevOps平台实现的典型案例和场景分析

下面对上面这些点做一个简单的展开说明

1. 传统软件过程和单体技术架构存在的问题和需求分析

再次说明一下,不要为了微服务和DevOps而去迎合,要业务和技术需求驱动,比
阅读  ┆ 转载 ┆ 收藏 
标签:

devops

微服务

分类: IT咨询
最近1到2年的博客文章,我谈微服务架构的比较多,而专门谈DevOps的比较少,包括对DevOps支撑平台和DevOps实践的一些关键点思考。19年准备对DevOps这块进行深入的了解和实践。在18年12月11日,当时写过一篇对DevOps实践价值的思考,其中的重点是在谈DevOps,容器云和微服务架构框架的三元一体化。只有三者相互结合才能够产生DevOps最佳实践。

DevOps = Dev + Ops + QA

对于DevOps首先还是要回到这个概念的最基础理解,即是开发,运维和QA工作本身的三元一体化。在有篇文章里面谈到一点,对自己很有启发,就是原来的软件开发流程,分工边界,包括了开发,SCM配置管理,QA,测试,运维等各个环节,相对来说分工明确,但是在核心软件交付流程中流转太多,自然导致效率低,同时也导致更多的上下游扯皮。

而DevOps带来的一个关键点就是,Dev处于整个核心交付流程中,而且这个过程通过方法工具等的支撑完全实现自动化和流水线作业,而对于SCM配置,QA等则处于核心流程的外围角色,即这些支撑过程角色不参与核心交付流程,只是对交付完成的内容进行管理验证。只有这样才容易实现整个交付
阅读  ┆ 转载 ┆ 收藏 
(2019-01-14 20:05)
标签:

随感

杂谈

分类: 随笔文章
最近1到2年的文章,我一般会总结一些工作和生活实践中的一些关键词,比如去年的一篇文章《实证》,实即真实可感受和触摸,证则实践证悟,对个人来说这是很重要的一个关键词,即必须要通过自我大量实践能够沉下来,而是空谈理论浮在上面。

再次强调,理论无法转理论,理论只能指导你实践,但是实践后才能转成适合你自己的方法论。

在实证这个概念后,今天提出另外一个个人认为相对重要的概念,就是盘感,盘感有点引申自我们下期的时候经常会用到的一个词,即下期的时候对整个盘面的感觉,指导你下步该如何走。而这里指的盘感,可以理解为我们从事一项专业性的工作时候,在长期工作实践后形成了一种对工作的熟练度,或者对工作中处理方法的隐性经验。这种感觉将有利于我们更加高效的分析和解决工作中的问题。

简单来说,盘感即熟练程度和经验积累度。

盘感借鉴到我们日常工作和生活,就是我们长期做一件事情所保持下来的熟练程度,以及在长期实践中不断累积的隐性经验。一旦我们中断一段时间,那么我们的熟练度一定会下降,而且可能又要经过一
阅读  ┆ 转载 ┆ 收藏 
(2019-01-13 10:59)
标签:

锻炼

分类: 随笔文章
本周跑满7天,跑步总里程52km,配速5'32'',这周7天跑步全部在北京科技大学校园完成,看了下自己最近1年的跑步记录,差不多一大半的跑步地点都是在北京科技大学。这一方面是北科大离我们租住的房子比较近,同时就是学校早上的校园很安静,校园环路也相对方正,一圈下来正好是2km的距离,也好自己进行测算。

最近虽然都在北京,但是由于天气比较冷,周末也没有去奥森公园跑步,主要是考虑到回程的距离差不多有3km多,这么远的距离要是跑完步后走回来的话很容易着凉,因此还是得小心为妙。近期各地感冒的人都很多,也是流感告发的一个季节,这个冬天在北京没有感冒过,但是12月回成都的1周多反而感冒了。北京虽然天气冷,但是气候干燥,屋子内又有暖气,反而不容易感冒。

最近1周跑步的配速明显慢了下来,一个是天气比较冷特意跑慢一点,一个是最近自己老出现胸口不时的疼痛,过完年后估计还得找个时间到医院彻底检查下。网上居然有种说法是说跟跑步多了或太频繁有关系,暂时还不清楚具体的原因在哪里。

跑步是一种生活方式,同时也是一种生活生态的体现。
阅读  ┆ 转载 ┆ 收藏 
标签:

中台

微服务

粒度

杂谈

分类: IT咨询
对于中台构建,实际上两个关键点,第一个就是划分微服务模块粒度,第二个就是在模块划分清楚后确定服务识别和定义的粒度。在将服务识别和定义前,可以先参考12月6日写的Rest接口设计这篇文章。


在上一篇谈中台构建模块划分的时候,我强调了一个关键点,就是尽可能以数据的维度来进行模块拆分,数据包括了基础主数据和核心共享数据,在数据驱动下拆分模块,那么模块底层对应的数据库本身如何拆分基本也就清楚了。一定要知道,微服务架构下,我们底层数据库也是拆分了的。

底层数据库没有拆分,但是仍然用SpringCloud框架开发,可以拆分为多个JAR包,在这种模式下只能认为是一个微服务模块,而不是独立,因为其不存在独立自治能力。我们看到很多上层开发采用SpringCloud框架,但是数据库仍然采用一个数据库的情况,再次说明,对于这种架构设计,不是标准意义上的微服务架构,没有做到彻底解耦。
阅读  ┆ 转载 ┆ 收藏 
标签:

中台

微服务

分类: IT咨询
在SOA和微服务架构体系下,或者说我们在构建企业中台能力层的时候,一个关键点就是微服务模块的划分,包括划分的方法,划分的粒度。今天就先谈下微服务模块的划分。

在IT应用架构规划大中台的概念下,实际上中台包括了技术中台和业务中台,对于技术中台重点是各个技术组件和技术服务能力的实现,而对于业务中台则主要包括了数据能力和业务规则处理能力的提供。对于业务中台本身也是分层,包括了最基本的数据类中心和业务处理类中心。

数据类中心本身又包括了基础主数据类和核心共享业务单据类,比如我们看到的产品中心,用户中心,属于基础主数据类。而对于订单中心,库存中心则属于业务共享数据类。

业务处理类则主要是进行核心业务功能和逻辑的处理,类似的包括了交易中心,结算中心,计费中心等,都可以看做是业务处理类的中台模块。当然,业务处理类中台也包括关键的领域服务提供组件,即这类组件需要调用底层更多基础原子模块的核心接口能力,经常组合后再提供出整合的组合能力。

技术中台模块的划分-完全垂直彻底解耦

阅读  ┆ 转载 ┆ 收藏 
(2019-01-10 20:11)
标签:

微服务

中台

杂谈

分类: IT咨询
在整个微服务架构,平台 应用的构建模式下,对于中台如何构建始终都是一个重要的关注点。中台本身就体现了SOA和业务的思想,体现了大架构规划设计中的微服务模块划分和服务识别。在前面自己也写过一篇关于微服务架构中台构建的文章,今年对于大中台的构建和思考将是一个重点。

对于大中台,可以看到谈的最多的仍然是在互联网电商类应用中,电商上层的业务应用类型太多,变化也快,需要有一个稳定,可共享,可复用的能力中心来提供中台能力。而对于各类运营商和服务商,类似电信运营商,大中台的构建更多体现在BSS域,即面向C端客户或政企B端客户的时候,渠道,网厅客服和业务办理,电商,自服务APP等,也都需要一个完整稳定,可共享能力的中台。

也就是说前台响应业务变化的需求也迫切,对敏捷的要求越高,越是需要有强大的中台能力支撑。共性的东西,基础可复用的东西我都不需要考虑,只需要考虑如何去应用能力和组装能力。

1. 大中台首先是一个由业务变更催生的业务概念

当我们一谈到中台的时候,很容易想到我们整体IT分层架构中中台层的构建,
阅读  ┆ 转载 ┆ 收藏 
(2019-01-09 20:22)
标签:

血酬

杂谈

分类: 随笔文章
在自己17年的文章写作里面,谈血酬定律是自己印象相当深刻的一篇文章,因为这个规律屡试不爽,所有违背这个规律的,都很难持续性的取得成绩。原来没有注意到《血酬定律》是一本在2003年就有过出版的书籍,准备下车图书购买的时候买来一读。

血酬,即流血拼命所得的报酬,体现着生命与生存资源的交换关系。血酬的价值,取决于所拼抢的东西。血酬是对暴力的酬报。由暴力所得,就是血酬,而血酬的多少,取决于暴力的强度,及暴力的承受者避祸免灾的意愿和财力。

血酬定律有三个要点:一、血酬就是以生命为代价从事暴力掠夺的收益;二、当血酬大于成本时,暴力掠夺发生;三、暴力掠夺不创造财富。

对于血酬定律,不仅仅讲的是需要你自己拼命或流血所换来的报酬或利益交换,这未免简单的将血酬理解为了一种暴力美学下的鸡汤,或不择手段下的唯利是图。而这些都不是重点,自己理解的血酬,更多的想谈下对于稀缺资源下,对竞争和自我投入的理解。

面对稀缺资源,一定就存在竞争关系,资源越是稀缺竞争也就越激烈。因此对于血酬不是简单的说
阅读  ┆ 转载 ┆ 收藏 
(2019-01-08 08:12)
标签:

推销

观人

分类: 随笔文章
昨天晚上做火车动卧从深圳到北京出差,同一节卡座里面刚好遇到两个中年妇女,其中一个40多岁,穿一个中长的妮子大衣,一条咖啡色的长围巾,手上戴两枚戒指,一个LV的大挎包,皮肤表现出和她年龄不相称的白皙和水嫩,给人感觉就是满脸玻尿酸包裹,我观察第一印象估计就是做微商的,或者做类直销传销或保健品推销的。

另外一个妇女应该有50出头的,在我下铺,也是一身的时髦打扮,但是再时髦也掩饰不了岁月在脸上留下的痕迹。这位大妈手推一个行李箱,身边只有一个小背包,身穿一件淡黄色毛衣,面色红润,颧骨略高,一眼往过去也明显能感觉到出门前是化了妆,涂了口红,修了眉毛,用时髦形容也不为过。

我一般北京深圳两地出差都以做火车动卧为主,睡一晚上就到也不浪费工作时间,上车后一般看下手机基本就开睡,最怕的就是同节卡座里面有大声大呼噜的。今天一上车遇到两个女士,心感还比较幸运,至少会遇到打呼噜的概率大幅度下降。但是不曾想到的的是,这个LV女士还真是做化妆品推销的微商或直销,两个人从一上车寒暄了没多久便聊了起来,一直聊到了11点多,虽然是否最终推销成功自己后来没有注意,但是间隙听到两人的
阅读  ┆ 转载 ┆ 收藏 
  

新浪BLOG意见反馈留言板 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有