加载中…
个人资料
人月神话
人月神话 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:4,062,426
  • 关注人气:5,899
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

微服务架构-文章阅读整理02(3.20)

(2019-03-20 08:38:02)
标签:

微服务

soa

分类: IT咨询
微服务架构-文章阅读整理02(3.20)

这篇作为我阅读知乎一个微服务专栏文章的笔记整理,方便后续阅读。
知乎专栏地址为: 
https://zhuanlan.zhihu.com/httpshop

微服务架构漫谈

这篇文章写的相对一般,读的时候要关注几点。首先对于SOA和微服务的区别这里,很多理解都有错误,SOA关注复用同样也关注解耦,SOA和微服务不存在底层数据库使用一个是偏关系型数据库,一个偏非结构化数据库的问题,这些都是对SOA的误解。前面我已经多篇文章谈到,微服务仅仅是SOA思想在单体应用内部应用的显性化,同时将接口集成轻量化。

微服务架构的优势和好处,前面文章讲的太多,重新回顾的话实际关键在两点

1. 进一步解耦后实现的高扩展性,而且这种扩展性还有容器技术结合进一步自动化
2. 提升后续的运维管控能力,使得后续的变更管理和发布影响范围最小

从业务上好处就是通过中台能力层的打造,实现了敏捷的快速组装和构建前台应用的能力

另外微服务架构本身的特点和最佳实践,不适合和DevOps的最佳实践混淆。类似持续集成,流水线,自动化单元测试等更多的是DevOps的最佳实践,而非微服务架构。

由浅入深带你走进微服务架构的核心

微服务架构的核心究竟在哪里?实际上前面很多文章都谈到过,要了解微服务架构需要了解两个区别,一个是微服务架构和传统的单体应用架构的区别,一个是微服务和SOA的区别,理解清楚这两个区别基本就了解了微服务架构的核心,即以下两点:

1. 将传统单体应用拆分为了多个实现单一能力职责的微服务模块,并独立自治包括数据库。
2. 各个微服务模块间是以轻量的Http Rest API接口进行通信

只要满足上面两点,基本就可以说满足了微服务架构的核心特征。其次微服务架构的技术栈,文章里面还是结合了DevOps和容器技术一起在谈,这个问题不大。实际上三者关系也相当紧密,在前面我的很多文章也都谈到过。即基于容器化PaaS+K8s+SpringCloud+API网关形成完整的技术架构和能力。

应用架构演进史

天下大事,分久必合,合久必分,分中有合,合中有分。这就是整体应用架构的演进。

就企业信息化业务领域也可以看到,就最初上一个大一统的ERP业务系统,到拆分为围绕ERP的多个外围业务系统,形成垂直烟囱化的构建模式,大量信息孤岛。再到围绕平台+应用理念来实现共性能力下沉解决信息孤岛问题,再到打破原来的业务域和业务系统边界,实现真正的模块化和组件化,提供核心能力中台来支撑上层应用。整个过程都可以看到从垂直独立到集中,再由集中到分布式拆分的过程。

从单体式架构迁移到微服务架构

对于传统架构朝微服务的迁移,我博客文章上也专门谈及过。在作者这篇文章给出三种迁移策略,即将新功能以微服务方式实现;将表现层与业务数据访问层分离;将现存模块抽取变成微服务。而实际上忽略了一个最重要的点就是数据库本身的拆分,如果仅仅是应用逻辑层拆分,而数据库还是用一个,不能称为完整的微服务架构。

对于应用层的拆分,我一直在思考两种思路如何选择使用的问题,具体如下两种思路:

1. 首先按中台+应用层进行拆分,识别中台能力中心,再来考虑前端应用组件模块。
2. 首先按业务组件进行纵向能力拆分,拆分完成后再按前后端微服务模块进行拆分。

从对SOA思路贯彻角度来讲,第一种拆分访问往往更加值得推荐。

谈谈微服务架构中的提取基础组件

采用微服务在梳理完业务应用流程之后,首先就需要考虑提取基础公共组件。这些组件是每个应用系统都可能需要用到的,所以这些组件需要首先提取出来。比如日志服务、监控服务、告警服务、统计服务、权限服务、认证服务等。

这个在最早的私有云PaaS平台规划建设中就谈到过,这块是属于PaaS平台的技术服务能力提供,而每一个技术服务能力就可以看做一个基础组件,也可以看做一个微服务模块。这些技术服务能力本身是和业务不相干的,包括安全,日志,缓存,文件,消息,任务等各种能力。但是要注意的就是技术组件提取的越多,那单个微服务模块本身的耦合性和对底层技术中台的接口依赖性也就越强。

微服务构建思路与方法论

如果谈微服务架构思路和方法论,结合我们前面谈到的微服务架构核心,最关键的点还是在微服务模块的拆分,API接口服务的识别和定义上面。即我一直强调的业务能力组件化,组件能力服务化。

究竟如何组件化,每个微服务模块粒度多大,暴露的API接口服务粒度是否合适这些才是微服务构建的关键。对于文章里面谈到的基于主数据思想来构建可以参考,但是会比较片面。真正的微服务构建,重点还是在对组件化业务架构建模,领域设计,平台化服务化思想,包括能力中台建设思想等方面。

而对于能力中台建设,我前面也有文章谈到,确实按照数据域的松耦合来划分中台模块是可行的,有类似基础纾解主数据的中台模块,也有提供核心共享数据的中台模块,还有业务处理和逻辑实现的中台模块。可以先考虑数据模块,再考虑业务处理和规则处理模块,再考虑流程类模块的思路来构建微服务。

0

阅读 收藏 转载 喜欢 打印举报/Report
  

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

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

新浪公司 版权所有