为了账号安全,请及时绑定邮箱和手机立即绑定

架构风格:微服务

标签:
架构

什么是微服务

「微服务」是一种架构风格,也就是说,「微服务」是一组架构约束

前面说到REST是一种复合式的架构风格,微服务也是!微服务的约束面更广,它对开发过程和开发人员也进行了约束

微服务的约束

MartinFlower在Microservices一文中,详细阐述了微服务所需要具有的约束!

- Componentization via Services:基于服务的组件化
- Organized around Business Capabilities:围绕业务能力进行组织
- Products not Projects:产品而不是项目
- Smart endpoints and dumb pipes:智能终端和静默管道
- Decentralized Governance:去中心化治理
- Decentralized Data Management:去中心化数据管理
- Infrastructure Automation:基础设施自动化
- Design for failure:容错性设计
- Evolutionary Design:进化式设计

实际上这些约束回答了架构设计所关心的几个问题:

  • 系统如何切分:围绕业务能力进行组织,去中心化数据管理

  • 模块之间如何通信:基于服务的组件化,智能终端和静默管道

  • 如何进行技术选型:去中心化治理

  • 容错性:容错性设计

  • 扩展性:产品而不是项目,进化式设计

  • 可维护性:基础设施自动化

下面一个个的说明!

系统如何切分?

在「架构风格:万金油CS与分层」一文中,最后提到,一般情况下,当你不知道一个系统使用何种架构比较好时,可以先使用分层架构。分层架构就是将系统一层一层的切分,下层为上层提供服务。

每一层的边界是什么呢?是「系统功能」!展现、业务逻辑、数据存储。你会发现,这种切分方式和业务本身没有任何关系,所以才是「万金油」!

另外,这种切分方法也将开发人员划分成了前端、后端、DBA!这是目前主流的做法,好像也没有出现什么大问题!

如果你在大公司待过,你就会发现进行一个需求变更是多么麻烦的一件事。即使一个很简单的需求,都可能要所有团队都参与进来。

导致这个问题的原因是什么呢?是沟通成本!

项目管理算法的复杂度是O(N 2),当人员变得越来越多时,沟通成本成倍增长:

  • 5人团队,需要沟通的渠道是 5*(5–1)/2 = 10

  • 15人团队,需要沟通的渠道是15*(15–1)/2 = 105

  • 50人团队,需要沟通的渠道是50*(50–1)/2 = 1,225

  • 150人团队,需要沟通的渠道是150*(150–1)/2 = 11,175

我们都知道「技术是为业务服务的」!如果一个架构和业务没有关系,如何为业务服务呢?如果沟通要花费大量的时间,如何快速推进项目呢?

所以,微服务「围绕业务能力进行组织」!

  • 既包括了系统的切分

  • 也包括了对人员的组织

因为康威定律提到:

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." - Melvin Conway (1967).

在微服务中,每个模块(这里的模块和我们平常所理解的模块有些区别,它的粒度更大,所以在微服务里一般称为是服务,下面均使用「服务」)都是一个完整的业务系统!包括了展现、业务逻辑和数据存储!相应的,负责开发的人员需要具备开发这个服务所需要的所有技能!

也就是说,在微服务中服务的边界是业务的边界

这很类似韩都衣舍的「以产品小组为核心的单品全程运营体系(IOSSP)」!将企业划分为“小集体”,像自由自在重复分裂的“阿米巴”——以各个“阿米巴”为核心,自行制订计划,独立核算,持续自主成长。以3人一组的产品组为例,这三个人分别是设计师、页面制作、库存管理员。这三人全权负责某一单品的页面制作、款式设计、尺码以及库存深度的预估等工作。

对应到微服务中,即两到三个人负责一个服务,这个服务包含了完整的业务流程,开发人员需要掌握开发这个服务所需要的完整的技能,包括UI、编程、DBA!

这里的难点是:

  • 一是要划分好业务边界,使得每个服务能够高内聚、低耦合!

  • 二是制定规范,利于各个服务之间的通信

  • 三是人员技能的要求更高

如何进行业务划分,需要根据具体的业务来具体进行。这里暂不展开。只提一点,就是要将事务考虑在内

就是说在切分系统的时候,要考虑事务问题!我们都知道远程事务是一个比较难处理的问题!两阶段提交、三阶段提交都不能很好的解决分布式事务问题!Paxos算法过于复杂,且性能较差。

所以微服务的建议是:

  • 尽量保证事务在一个服务中执行

  • 通过补偿的方式来弥补事务操作的问题

服务如何通信?

对于一般系统来说,我们都是使用的进程内通信,即通过调用同一内存内的方法的方式进行通信!公用的代码我们可以以「库」的形式进行组织,避免代码重复!这种系统我们一般称为「单体系统」!

「单体系统」的伸缩性不理想!比如说,双11需要做个活动,瞬间用户量大增!如果需要应对流量峰值,就需要对系统进行扩容。但是因为是单体系统,扩容只能整体扩容,而实际上需要扩容的只是那个活动页面!这就导致了资源的浪费。另外一个问题就是,如果这个活动导致了系统崩溃,这将导致这个系统的所有功能都不能使用!

一种解决方案是进行「服务化」!即将需要多个系统公用的逻辑或TPS较高的模块独立部署,通过进程间通信的方式,进行服务调用。比如上面的活动模块,当活动模块以服务的方式对外服务后,需要扩容时,只需要扩容活动服务就可以了。同时,如果活动服务出现了问题,只会导致这个活动相关内容无法访问,而不会影响系统的其它功能。今年双11淘宝的地址服务就挂了,但是并不影响淘宝本身的访问。

这里所说的「服务化」是使用dubbo这类服务化框架进行的服务化,而不是使用ESB的SOA!

基于ESB的SOA主要是为了将企业中的各个系统连接起来!ESB像一根「聪明」的管道,用来连接各个「愚笨」的节点。为了集成不同系统,不同协议的服务,ESB做了很多事情:

  • 消息路由

  • 编排

  • 转换

  • 业务处理规则

这就导致ESB很重、很复杂。这也是基于ESB的SOA被人诟病的一个原因。

dubbo这类服务化框架主要解决的是运行时代码复用、系统伸缩性以及高性能问题!但是服务粒度相对较小,带来的问题就是维护的成本相对较高

而微服务可以说做了一些折中:

  • 服务粒度较大,包含了一个完整的业务的展示、逻辑和存储。相对的数量就较服务化少,维护相对较容易

  • 以进程间通信的方式提供服务。包括对外服务、以及其它服务。保证了伸缩性。

  • 业务逻辑处理都在服务内部进行,通信组件只提供单纯的通信功能。保证了简单性。

这样既摆脱了繁重的ESB,也降低了维护难度!

如何进行技术选型?

对于「如何进行技术选型」,微服务不强制开发平台!因为「没有银弹」!微服务偏向于「适合的工具解决适合的问题」!

每个程序员都有自己喜欢的技术体系!有喜欢Java的、有喜欢.Net的、有喜欢C++的,还有喜欢Lisp的。。。。

那开发系统时需要选择哪种技术体系呢?按微服务的观点就是:哪种技术合适就用哪种技术吧!这个服务需要高并发,可以用Go来进行开发!这个服务需要快速推进,可以用PHP!这个服务需要稳定,可以用Java!看起来很完美!

而实际上内,这导致的是不可控!为什么Java语言会被很多企业使用?其中一个原因就是可控

举个例子,国内公司的技术栈相对比较单一!比如,公司的主流语言是Java,.Net,PHP等,其它语言就只是辅助!一般不会有两种、甚至三种主流语言!
假设一家公司的主流语言是Java!开发一个系统,可能需要10个人。那公司可以招5~6个一般的,2~3个不错的,1个牛逼的!公司只要稳住那个牛逼的就行了!如果有人走了,只要其他人顶上就行了!
而如果每种服务都使用不同的语言,那一个系统使用了三个左右的语言,每种语言得有个熟练掌握的吧?每种语言,公司都得稳住个相对牛逼的吧?成本高不说,难度也大了不少!

容错性

系统按照业务切分为一个个的服务,相对单体应用来说,运行的系统多了,系统整体不可用的几率降低了,但是单个服务出现问题的几率却变大了!这就需要微服务系统需要有比单体应用更好的容错性!

任何服务可能因为供应商的不可靠而故障,客户端需要尽可能的优化这种场景的响应。与单体构架相比,这是一个缺点,因为它带来额外的复杂性。这将让微服务团队时刻需要关注服务故障的情况下的用户体验
由于服务可能随时出现问题,所以快速故障检测,甚至自动恢复就变更非常重要。微服务应用把实时的监控放在应用的各个阶段中,检测构架元素(每秒数据库的接收的请求数)和业务相关的指标(每分钟接收的订单数)。监控系统可以提供一种早期故障告警系统,让开发团队跟进并调查。

这又无形中提高了对开发人员的技术要求!

扩展性

对于互联网产品来说,这是个必选项!

以前在网上看到过一句话,大意是:「当你有一个想法的时候,世界上可能有1万个人也有这个想法!其中1000个人已经开始做了!100个人已经做完了!10个人已经运营了!1个已经盈利了!」

也就是说,相同的产品千千万。用户为何就偏爱你这款?

你的系统需要有核心竞争力,来吸引新用户!同时还需要不断的加入新功能,保持用户不流失!

可维护性

服务的数量增加了,维护的成本也就相应的增加了。除了上面提到的通过降低沟通成本来提高可维护性外,微服务还通过「基础设施自动化」来降低维护难度!

基础设施自动化有如下几个原因:

  • 由于微服务的服务较单体应用会多了很多,这就导致了部署微服务较部署单体应用来说要复杂得多。单纯的靠运维来手动部署不现实

  • 部署的服务较多,且是网状通信,导致了一个请求可能会调用多个服务,对于请求的追踪不能像单体应用一样,靠日志来跟踪。需要追踪请求。

  • 当请求异常时,或服务异常时,需要能自动的处理一些常见情况(也涉及上面的「容错性」)

参考资料

原文出处:https://www.cnblogs.com/ivaneye/p/9967383.html  

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消