架构演进之「微服务架构」

“为什么要搞「微服务架构」”?这也是我们当初讨论的聚焦点。现在天天把“微服务”挂在嘴边的人很多,但是有多少人真正深入思考过“为什么”,我认为可能不多。

于是我在梳理材料的时候,就决定从源头入手——即“为什么”。

架构是演进的,不是一蹴而就。

“架构演进趋势图”中的趋势分析,在业界比较公认。这个图本身的内容、关于各个架构的描述、优缺点等等,网上简单搜索一下有大把大把的,感兴趣的同学可以自行搜索,毕竟这也不是我们文章的重点。

软件发展的不同时期、阶段,对技术的理解、选择和应用都有着不一样的诉求。架构的选型,永远只有“合适与不合适”,永远没有“哪个更好”的说法。我们今天来谈论微服务,并不是因为它更牛,而是经过谨慎分析,认为微服务的思想更符合我们的目标。

什么是「微服务架构」?


既然聊的是“为什么”,那么首先要明白“什么是”。

「一解释就懂,一问就不知,一讨论就打架」,这是之前我在网上看到的一句话,笑了好久,太贴切了,就搬了过来。

提到微服务,就没法不提到这位“大神”——马丁·福勒,他没有直接给微服务下一个精准的定义,而是给出了微服务特点的描述,大概从以下四个方面来说:

1.根据业务模块划分服务种类
2.每个服务可以独立部署并且互相隔离
3.通过轻量的API调用服务
4.服务需要保证良好的高可用性


怎么理解呢?以下是我的解读:

第一点,按业务拆分服务,这是“水平拆分”;在技术层面的“前后分离”,属于“垂直拆分”;横纵一起切,就把单一的应用拆分成网状的小块应用,这是微服务中「微」思想的体现。

第二点,独立部署与互相隔离,这点充分体现了“我为人人、人人为我”的设计理念,这是微服务中「服务」思想的体现。

第三点,关于轻量API,微服务本身是推荐使用轻量的通讯协议和简单的数据结构,实际上,实施环节通常采用的都是http+json的方式。这样做的好处是,服务之间不再需要关心对方的模型,仅通过事先约定好的接口来进行数据流转即可。这是微服务中「解耦」思想的体现。

最后一点,比较通用了,就是现如今各种设计都必须考虑的事情。

于是,我给微服务下了一个定义(如图)。

在实际工作中,我们遇到过各式各样的问题,有些是技术问题,有些是业务问题,还有些是管理问题,这里拿其中一个案例来说一下。


这种事情说大不大,说小不小。其中最麻烦的事情是“推诿”的发生。每个独立组织都有自己的考核指标和关注点,而实际情况又不可能把具体的一个任务的界限划分得特别清晰。例如接口定义,哪怕说的是“双方坐下来一起商讨决定”,最终还是会有一方对此事负责,推诿在所难免。

微服务的指导思想其中一块就是关于组织机构调整的,这还有个专门的定律叫“康威定律”,感兴趣的可以自行搜索了解。

我们的解决办法也很有效果。在组织机构没有完全按照微服务的理念重新规划之前,这类需要跨组织协同完成的任务,直接成立临时项目组:相关的部门出人的出人、出资源的出资源,指定/选拔一个能hold住的项目经理对整件事情负责,然后大家惊奇的发现:“部门墙”问题不见了,因为所有事情都是组内事情了,整体的完成情况跟全部项目组成员的业绩都挂钩了,事情推进就非常顺利。在顺利交付之后,项目组解散,各回各家。极大的提升了沟通效率、交付速度,同时使得资源利用率也得到了很大的提升。

其实很多时候,大家解决问题的想法和思路,并不是要有了微服务才这样做,而是“不谋而合”,微服务就存在于我们日常工作的点点滴滴之中。

有人问:我要搞微服务了,有啥建议么?

有的。通过我们不断的摸索和总结,要做好微服务,就要做好一定的准备工作,从四个具体的方面来谈:

业务拆分 – 体现在设计环节:在设计的时候,要有足够的判断力来合理的规划服务之间的界限。

服务治理 – 底层技术的支持:首先要选一款适合自己实际情况的分布式服务基础框架,对于服务的发现、治理、熔断、降级,都要做好相应的技术准备。

自动测试:一定要自动化。微服务一个明显的表象就是随着服务的增多,如果继续沿用传统的测试模式就会遇到瓶颈,为了保证高效的迭代,尽量做到更多的环节实现自动化。

自动运维 :微服务拆分之后,每个服务都可以独立部署,进而言之应该是随时随地可以升级。尤其当互联网发展到今天,业务要保持对市场变化的一个高效响应,自动化运维就是提升交付速度的一个重要环节。

最后一定要提的是「监控」:包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。「监控」在实施微服务过程中会重要到什么程度呢?一句话:没准备好监控,就不要搞微服务。

最后,微服务不是银弹,软件领域没有银弹,微服务以其特有的优势在解决一些问题的同时,也引入了其他问题,这几点,必须要深刻的思考。

「三思而后行」。

———————————————分割线————————————————
我是小微,专注微服务技术分享,致力挖掘更多“高、精、全”的微服务知识分享给大家。
我的微信:weiweiweiblack (备注:51CTO )
微信公号:黑少微服务,“分享技术,热爱生活”,欢迎关注

原文地址:http://blog.51cto.com/14020773/2311039

时间: 2024-10-07 16:01:29

架构演进之「微服务架构」的相关文章

架构设计之「 微服务入门 」

微服务这几年不可谓不火,很多技术团队都开始在自己的项目上引入了微服务.一方面这些团队确实很好的推动了微服务的应用和发展,另一方面也可以看到一些盲目追技术热点的行为所带来的危害,比如很多中小团队对微服务的基础知识只是做了很浅显的了解就开始盲目的推动微服务的实施,最后导致了项目的失败. 微服务要想做好是一个非常复杂的架构,今天就先只聊一聊微服务的一些基础架构,算是入门篇. 一.什么是「 微服务 」? 「 微服务 」由 Martin Fowler 提出,它是指一种软件架构风格.一个大型的系统可以由多个

Atitit.架构设计趋势 设计模式 ---微服务架构  soa

Atitit.架构设计趋势 设计模式 ---微服务架构  soa 什么是微服务架构?1 .微服务与SOA的关系 :微服务架架构师面向服务架构(SOA)的一种特定实现1 微服务与康威定律2 微服务的一些设计 断路器 幂等2 <微服务设计>([英] 纽曼(Sam Newman))3 微服务架构与实践4 什么是微服务架构? Martin Fowler认为,微服务架构是一种独立部署的软件应用设计方式.这种架构方式没有准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上有着共性.

Re:从 0 开始的微服务架构--(四)如何保障微服务架构下的数据一致性--转

原文地址:http://mp.weixin.qq.com/s/eXvoJew3bjFKzLLJpS0Otg 随着微服务架构的推广,越来越多的公司采用微服务架构来构建自己的业务平台.就像前边的文章说的,微服务架构为业务开发带来了诸多好处的同时,例如单一职责.独立开发部署.功能复用和系统容错等等,也带来一些问题. 例如上手难度变大,运维变得更复杂,模块之间的依赖关系更复杂,数据一致性难以保证,等等.但是办法总是比问题多,本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的. 微服务架构的数据一

个推首席架构师Qcon分享 |微服务架构的那些事儿

微服务架构需要注意哪些问题? 微服务架构,首先考虑客户端与服务端之间的通信问题.有两种解决办法,一是客户端与多个服务端直接进行通信,但存在对外暴露接口细节.众多接口协议无法统一.客户端的代码复杂.服务端升级相对困难等问题.二是客户端访问统一的API网关,由API网关调用众多服务接口,易实现统一通信协议,降低客户端和服务端代码耦合,也可以达到统一的鉴权和流控,然而此方式存在延时增加的风险,可能使API网关成为系统发展的瓶颈. 微服务架构是分布式服务架构,如何进行服务的注册和发现也是需要解决的问题.

百度“百老汇”架构师深刻透视微服务架构

首先解释这个"百老汇"=百度老年架构师活动中心.......什么是微服务首先微服务并没有一个官方的定义,想要直接描述微服务比较困难,我们可以通过对比传统WEB应用,来理解什么是微服务.传统的WEB应用核心分为业务逻辑.适配器以及API或通过UI访问的WEB界面.业务逻辑定义业务流程.业务规则以及领域实体.适配器包括数据库访问组件.消息组件以及访问接口等.一个打车软件的架构图如下: 尽管也是遵循模块化开发,但最终它们会打包并部署为单体式应用.例如Java应用程序会被打包成WAR,部署在T

SOA和微服务架构的区别?

知乎用户 289 人赞同了该回答 谢多人邀请,其实前面几位的回答已经差不多了,在这里仅谈下自己的简单总结. 微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身

SOA和微服务架构的区别

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务. 如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较

微服务架构的两大解耦利器与最佳实践

这几年,微服务架构这个术语渐成热门词汇,但它不是一个全新架构,更不是一个包治百病的架构.那么,微服务架构究竟能够解决什么问题,又带来哪些痛点? 本文将与大家谈谈这个问题,以及微服务架构的两大解耦利器配置中心和消息总线的最佳实践. 微服务架构解决的问题与带来的痛点 一 互联网高可用架构为什么要服务化? 上图是互联网典型的高可用架构,大部分公司如果没有使用微服务,正在使用这样的架构: 用户端是浏览器 browser,APP 客户端 后端入口是高可用的 nginx 集群,用于做反向代理 中间核心是高可

从 Spring Cloud 开始,聊聊微服务架构实践之路

[编者的话]随着公司业务量的飞速发展,平台面临的挑战已经远远大于业务,需求量不断增加,技术人员数量增加,面临的复杂度也大大增加.在这个背景下,平台的技术架构也完成了从传统的单体应用到微服务化的演进. 系统架构的演进过程 单一应用架构(第一代架构) 这是平台最开始的情况,当时流量小,为了节约成本,并将所有应用都打包放到一个应用里面,采用的架构为 .NET SQL Server: 表示层:位于最外层(最上层),最接近用户.用于显示数据和接收用户输入的数 据,为用户提供一种交互式操作的界面,平台所使用