标签:去中心化 行业 效率 包括 好友 服务 alt hellip 框架
微服务架构,是以专注单一责任的小型功能模块为基础、通过API集相互通讯的方式完成复杂业务系统搭建的一种设计思想
软件发展的不同时期、阶段,对技术的理解、选择和应用都有着不一样的诉求。架构的选型,永远只有“合适与不合适”,永远没有“哪个更好”的说法。我们今天来谈论微服务,并不是因为它更牛,而是经过谨慎分析,认为微服务的思想更符合我们的目标。
很久以前的一天,Martin 在跟好友的交流中悟到了一种很棒的架构设计。他总结了一下,然后告诉了好友,好友说,这不是新鲜东西,早有人总结了,叫做 SOA。
Martin 很高兴,开始在公司内外推广 SOA。结果,不停有人质疑和挑战他。
你这不是 SOA 吧?SOA 这里应该是如此这般的。对,这里我对 SOA 的理解是这样的。你看,这本 SOA 的书说的和你说的有出入。粒度?SOA 没有谈到这个呀,你这不是 SOA。分层跟 SOA 没有关系,你为什么要说这个呢?…
Martin 没办法,心一横,老子就叫它 Martin‘s SOA。老子发明的词,老子就是最高权威,有最终解释权。还有谁不服?
同事们一看,这思想本身很不错,值得推广,但叫 Martin‘s SOA 太没品了吧?还是要取个好一点的名字,最好还能跟 SOA 有某种暗示传承。干脆就叫 Microservices 好了,又新,又有服务含在其中。
Martin 忿忿地接受了这个建议,心里想着:妈的,明明就是 SOA,一群傻逼非要逼我取个新名字。
后来 Martin 发现每次提一个东西就会收到旧恶傻势力对解释权的挑战,所以每次要提一个什么概念,都去发明一个新词,免得一群人在那一边质疑挑战,一边大谈“我的理解”。
这就是微服务、敏捷、精益企业、持续集成、持续交付背后的故事。
一个名词产生之后,命名者的解释权就会随着时间而弱化(比如 Cooper 发明的 Persona 就被无数设计师乱用)。敏捷已经有点烂了,等微服务也烂了,我们还会发明新词。
微服务的概念源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”。文中内容提到:微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。
每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。
另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。
微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。
在将应用分解的同时,规避了原本复杂度无止境的积累。每一个微服务专注于单一功能,并通过定义良好的接口清晰表述服务边界。
由于体积小、复杂度低,每个微服务可由一个小规模开发团队完全掌控,易于保持高可维护性和开发效率。
由于微服务具备独立的运行进程,所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。
由微服务组成的应用相当于具备一系列可并行的发布流程,使得发布更加高效,同时降低对生产环境所造成的风险,最终缩短应用交付周期。
微服务架构下,技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状,自由选择最适合的技术栈。
由于每个微服务相对简单,所以需要对技术栈进行升级时所面临的风险就较低,甚至完全重构一个微服务也是可行的。
当某一组件发生故障时,在单一进程的传统架构下,故障很有可能在进程内扩散,形成应用全局性的不可用。
在微服务架构下,故障会被隔离在单个服务中。若设计良好,其他服务可通过重试、平稳退化等机制实现应用层面的容错。
单块架构应用也可以实现横向扩展,就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时,微服务架构便体现出其灵活性,因为每个服务可以根据实际需求独立进行扩展。
从五个具体的方面来谈:
业务拆分,体现在设计环节:在设计的时候,要有足够的判断力来合理的规划服务之间的界限。
服务治理,底层技术的支持:首先要选一款适合自己实际情况的分布式服务基础框架,对于服务的发现、治理、熔断、降级,都要做好相应的技术准备。
自动测试,一定要自动化。微服务一个明显的表象就是随着服务的增多,如果继续沿用传统的测试模式就会遇到瓶颈,为了保证高效的迭代,尽量做到更多的环节实现自动化。
自动运维 :微服务拆分之后,每个服务都可以独立部署,进而言之应该是随时随地可以升级。尤其当互联网发展到今天,业务要保持对市场变化的一个高效响应,自动化运维就是提升交付速度的一个重要环节。
监控:包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢?一句话:没准备好监控,就不要搞微服务。
标签:去中心化 行业 效率 包括 好友 服务 alt hellip 框架
原文地址:http://www.cnblogs.com/xuwendong/p/7844778.html