微服务架构咨询和实施(11.18)

标签: IT咨询 | 发表时间:2017-11-18 15:01 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
从去年下半年开始到现在,团队花了大部分的精力在微服务架构的学习,工具融合和支撑平台研发上面。虽然今年的项目基本还是ESB服务总线类的传统集成类项目,但是经过大量的售前交流,以及和客户的沟通,对于微服务架构规划咨询和落地实施最终将成为传统企业IT架构转型的必然之路。

在博客上我也专门讲过微服务架构,也讲过微服务架构和SOA,和ESB服务总线的区别,也专门写过阿里的《传统企业IT架构转型》这本书的读书笔记。从我最早在企业内部私有云PaaS平台建设中谈到的 平台+应用的构建模式,到组件化和服务化架构,到最近1年阿里谈的最多的中台战略和中心化,以及从传统的持续集成谈到现在的DevOps最佳实践,从传统以虚拟机为调度单位的PaaS平台到现在以容器化为主流的轻量PaaS

整个技术发展的相当快,最典型的特点就是 轻快+高性能,即面临快速变化的业务,传统的重型架构已经不合适。这和企业管理是一个道理,越是组织架构复杂,层级越多的企业往往转型也就越困难,业务处理流程和执行效率越低下。

转回到互联网来说, 业务变化快而且需要敏捷响应,那么我们的架构就必须轻量灵活,能够快速的适应变化,同时这种架构还必须要满足对高性能,高可靠性的要求。正是这个原因也可以看到,对于微服务架构,容器化和DevOps最早仍然是在互联网企业得到广泛的应用,并产生了大量的最佳实践。

那对于传统企业的IT部门是否需要引入微服务架构,其实答案很简单,即只要传统企业IT出现了业务需要快速敏捷响应的场景,那么就一定需要一种更加轻量高效的架构。首先要满足轻快的要求,其次才是满足降低成本的要求,业务驱动IT,IT建设最终为业务服务,那么企业IT部门就必须回答好建设的IT系统如何更好的为业务服务?

今年团队将大部分研发重心放到微服务架构上,还有一个核心原因就是微服务架构真正将团队原来在SOA,云计算,软件项目管理和过程改进,敏捷方法论方面的最佳实践融合在一起,而只有这些真正融合才可能为企业提供一个完整的微服务架构解决方案。

这篇文章之所以叫微服务架构咨询和实施,是想说明在帮助企业进行微服务架构转型和推进过程中,远行科技究竟可以提供哪些支持和服务能力,具体来讲可以分为如下几个方面:

架构咨询服务能力


团队首先能提供,也是相当重要的一部分能力就是架构咨询能力,即需要回答企业的传统IT架构如何转型微服务架构以及如何演进?其次需要回答究竟如何划分微服务模块或组件,或者类似阿里谈到的各个中心(类似产品中心,客户中心,订单中心,库存中心)等,再次还需要在划分好微服务模块后进行关键的业务流程和场景的梳理和分析,识别每个微服务模块究竟应该保留哪些微服务API接口。

归根到底还是我原来强调到的一句话, 即业务能力组件化和组件能力服务化,咨询服务最终给企业提供的就是划分出最合适的模块单元,并识别最容易复用,粗粒度的微服务API接口。

在传统的ESB服务总线实施和集成项目中,我们进行的SOA架构咨询,服务架构和目录库规划仍然是我们提供的相当有价值的服务。不管是ESB总线,还是微服务网关,最终都是技术平台,真正重要的是最终接入到平台上的服务究竟如何?

微服务架构基础框架

注意这里的基础框架涉及到多个方面的内容,包括了Spring Cloud微服务架构框架,也包括了k8s+Docker容器,还包括了类似开发工具环境,Jekins,Maven,JUnit各种工具的集成,DevOps最佳实践的落地等。这些都和微服务架构密不可分。也是我常说的微服务架构+容器化+DevOps是三个最核心的内容。

远行不仅仅是将这些开源的工具包进行完整的组合,形成一套标准的组件化开发方法和工具模板,同时提供一个完整的管理平台,可以实现灵活的模块定义,服务接入,自动构建和打包,流水线管理和环境迁移,灰度发布等完整的DevOps过程。同时还将类似项目管理,缺陷管理和看板,类似用户故事的条目化需求管理和跟踪全部集成进来,形成一套参考敏捷方法论的软件支撑过程平台。

这些不是简单的工具累加,而是团队多年的最佳实践当然融合。

监控和运维支撑平台


相对于传统的业务系统间的接口服务集成,在实施微服务架构化后接口服务会呈现指数级的增长,虽然各个微服务模块更加容易进行组合,服务也容易灵活编排,但是在整个应用全部上线后对于诸多的微服务模块的自动化运维,实时动态监控和预警就成为相对关键的内容。

在阿里的《传统企业IT架构转型》这本书里面专门提到了鹰眼应用,即通过鹰眼应用 实现了整个微服务架构下所有微服务模块,微服务API接口的实时监控,服务链监控和跟踪,性能分析,实时告警。这些都是微服务架构下应用实施上线后最需要的能力。

微服务架构下的监控和运维支撑平台和传统的监控平台有比较大的区别,其一是更加强调类似APM应用性能监控层面的内容,其二是强调服务链监控和跟踪,其三是更加强调监控的实时性和预警能力。同时我们在监控能力植入的时候还需要做到尽量不影响已有功能的性能。

 

相关 [微服务 架构 咨询] 推荐:

微服务架构咨询和实施(11.18)

- - 人月神话的BLOG
从去年下半年开始到现在,团队花了大部分的精力在微服务架构的学习,工具融合和支撑平台研发上面. 虽然今年的项目基本还是ESB服务总线类的传统集成类项目,但是经过大量的售前交流,以及和客户的沟通,对于微服务架构规划咨询和落地实施最终将成为传统企业IT架构转型的必然之路. 在博客上我也专门讲过微服务架构,也讲过微服务架构和SOA,和ESB服务总线的区别,也专门写过阿里的《传统企业IT架构转型》这本书的读书笔记.

SOA架构咨询

- - 人月神话的BLOG
对于SOA架构咨询,其核心还是在于组件化和服务化,然后才是服务管控和治理,基于服务化思想对传统软件开发生命周期过程的改进. SOA架构大家刚接触时候很容易将其理解为一种单纯的技术架构,或者更多的人仅仅是将SOA理解为service服务接口,这些都是对SOA方法论很大的误解. SOA咨询一个重点就是业务驱动IT,而非单纯的IT架构咨询,SOA咨询一般都会结合企业架构和云的思想,结合组件化架构和领域服务的思想,高层结合BPM端到端流程整合目标,并对这些内容进行有效的融合.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

企业架构和IT规划咨询

- - 人月神话的BLOG
企业架构,业务架构,数据架构. 我们将核心价值链上的端到端总结为两个核心,其一是供应链的端到端流程和业务;其二是产品研发的端到端和业务. 各个企业由于类型不同往往对两条价值链各有 侧重. 生产代工类企业没有自己的产品研发,那么只有供应链;高科技研发企业可以做到卖产品核心技术和专利,不做具体供应链方面事情.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.