那些年你不知道的微服务架构的九大特性

关键词：

图灵学院 java架构师学习路线

 

微服务的九大特性

特性一：组件化与多服务

软件开发一直以来都有一个梦想：像搭积木一样来构建应用，尽可能的模块化、组件化，方便可更换可升级的目的。

一个组件就是一个可以独立更换和升级的软件单元。

在微服务架构之前，构建单体应用之时，大家也是朝这个目标努力，一个很好的例子就是使用各种公共软件库。公共软件库也算组件的一种形式：一定程度上可更换可升级。

但使用公共软件库构建应用的一个很大的问题是：一旦公共软件库升级后，就需要重新构建部署整个的应用系统，即使别的组件没有变化，也要这么做，这种不合理因素就逐渐凸显出来。

微服务作为组件的更高级形式，解决了这个问题：服务可以被独立部署，对一个服务修改只需要构建和重新部署这一个服务，对系统的其它服务没有影响，但前提是服务的接口协议没有发生变化，只是服务内部的升级。如果涉及到服务的接口协议的升级，那么情况就要复杂一些，跟调用这个服务相关的其它服务可能也会修改升级。

特性二：围绕业务功能组织团队

** 著名的康威定律：**

任何设计系统的组织，都会产生这样一个设计，即该设计的结构与该组织的沟通结构相一致。

——梅尔文•康威（Melvyn Conway）, 1967

根据康威定律，当面对一个大型的应用系统时，管理层会根据目前的组织架构来分解系统：前端团队负责用户界面，后端团队负责后端服务，数据库团队负责数据库运维，一个根据组织架构而产生的设计架构应运而生——又一个单体怪物的雏形开始孕育。

而微服务的架构自然而然的打破了这种组织的界限，因为微服务采用”业务功能“来分解系统，而针对各个业务功能需要提供多层次广泛的软件实现，包括用户界面、数据库存储以及对外的协作等，那么开发微服务的团队就需要是跨职能的，拥有软件开发所需的全方位技能。

这对团队组织是一个新的挑战，但也在不确定中孕育着新的契机。

特性三：做产品而不是做项目

传统的应用系统开发模式是项目模式，开发团队负责开发，开发完成后移交给测试团队测试，测试完成后再移交给运维团队部署运行。一旦系统部署上线，之前的开发团队就认为万事大吉了，开始转向下一个项目。

微服务强调采用产品模式：构建微服务的团队对其整个的生命周期负责，包括部署上线以后。最著名的理念就是亚马逊提出的”谁构建，谁运行”，开发团队对一个在生产环境下运行的软件负全责。

这样做的好处不言而喻，相信任何开发人员都不希望在大周末陪家人享受幸福时光的时候被电话叫回公司修复线上的Bug，特别是那个服务还是自己构建的。这对自己将是一种刻骨铭心的痛。

特性四：智能端点与傻瓜管道

我个人认为这个特性是老马的博客中比较难理解的一部分，因为作者引入了两个比较抽象的概念——智能端点和傻瓜管道。

什么是智能端点，什么是傻瓜管道？这需要从微服务的运作特点来理解。

微服务是依照”业务功能“来构建，那么它的实现目标就是尽可能的”高内聚和低耦合”，微服务内部拥有独立而完整的业务逻辑，微服务之间像管道（Pipe）那样传递消息流。这种模式就像经典的Unix系统上过滤器（filter）的工作机制，接收请求，按照业务逻辑进行处理，最后产生响应消息。

智能端点就是指拥有独立而完整的业务逻辑的微服务，它们从管道上获取消息，进行智能处理，然后产生处理后的消息，放回管道。

傻瓜管道就是指连接微服务进行消息传递的通信机制，它们只负责消息流的传送，不承载更多的关于业务逻辑上的分析和处理。

傻瓜管道的协议类型通常有两种：同步的协议类型，比如REST风格的HTTP协议和轻量级的RPC协议（Thrift等）；异步的协议类型，比如各种消息队列(Apache kafka等）。

特性五：去中心化地治理技术

我认为这个特性是使用微服务最明显的优势，每一个微服务都可以采用最适合的技术栈来构建，而不至于像原先构建单体应用那样，统一到单一的技术平台和标准。

想要使用Node.js来搞出一个简单的报表页面？尽管去搞。

想用C++来做一个特别出彩儿的近乎实时的组件？没有问题。

想要换一种不同风格的数据库，来更好地适应一个组件的读取数据的行为？可以重建。

It‘s cool for programmers!

做自己擅长的事，并把擅长的事做到极致！——这句话也很好地表述了微服务的精神特性。

特性六：去中心化地管理数据

传统的应用系统使用一个中心的数据库来管理数据，这样方便事务操作，可以保证数据的一致性。

微服务主张数据去中心化，各个微服务拥有自己内部的数据存储方案，对外不暴漏数据的细节，跟外部打交道的只有设计良好的API。

但是这种数据模式的变化，对于数据的一致性保证是一个巨大的挑战。微服务的这种数据方式使得事务操作不再可行，而且通过简单的视图方式展现数据的方法也不再可能。这真是一件令人头疼的事情啊！

但微服务要想朝着高内聚低耦合的目标努力，就必须这样分而治之，别无选择！

我们能做的就是应对这个挑战，拿出切实可行的方案解决这个问题。但如何解决，老马没有展开说。这一点我们团队在实践中做的也不好，需要更多的探索和尝试。

特性七：基础设施自动化

微服务架构的实施跟自动化技术密不可分，也可以说，没有自动化技术的支撑，微服务架构的实施会遇到瓶颈。

为什么这么说呢？因为一个大型的应用系统，如果采用微服务的架构，意味着可能会有成百的微服务被构建出来，这种数量规模的微服务系统，相对于之前的单体应用系统，在构建、部署和运维上要复杂很多，如果单靠人工操作，没有自动化流程的支撑，将是一场噩梦。

当然，基础设施的自动化技术在近几年里飞速发展，特别是各种云平台的出现，已经大大降低了构建、部署和运维微服务的操作复杂性。这是一个非常好的发展微服务的契机。

微服务构建、测试、部署这个流水线的自动化是必不可少的，大致包括几大方面：

• 自动化测试

   

• 编译

• 单元测试

• 功能测试

• 验收测试

• 集成测试

• 用户验收测试

• 性能测试

   

• 自动化部署

   

• 部署到构建的环境

• 部署到集成的环境

• 部署到用户验收测试的环境

• 部署到性能测试环境

• 部署到生产环境

   

特性八：容错设计

单体应用分解成诸多独立的微服务，虽然有诸多的优点，但凡事必有两面性，你享受微服务优势的同时，也必然要忍受其缺陷。

而使用微服务架构的一个很大缺陷就是故障发生的概率将会成倍的增加，所以对应的就需要为此添加很多的容错设计。

总结一下这个问题，就是：当服务提供方不可用时，客户端如何优雅的应对这种情况？

具体的应对措施有以下几种：

• 网络超时：当等待响应时,不要无限期的阻塞,而是采用超时策略。使用超时策 略可以确保资源不会无限期的占用。

• 限制请求的次数：可以为客户端对某特定服务的请求设置一个访问上限。如果请 求已达上限,就要立刻终止请求服务。

• 断路器模式：记录成功和失败请求的数量。如果失 效率超过一个阈值,触发断路器使得后续的请求立刻失败。如果大量的请求失败, 就可能是这个服务不可用,再发请求也无意义。在一个失效期后,客户端可以再试, 如果成功,关闭此断路器。

• 提供回滚：当一个请求失败后可以进行回滚逻辑。例如,返回缓存数据或者一个 系统默认值。

   

特性九：演进式设计

在这一部分，专家们对微服务技术采取谨慎保守的态度。

这是可以理解的，因为任何完美的系统都不是一蹴而就的，都有一个从无到有，从小到大的演化过程。

专家们建议，从一个单块系统作为起点，保持其模块化，当这个单块系统达到一定的规模，开始出现问题后，再将其拆分成微服务，是一个不错的开始。我很认同这个建议，因为这是一个可行的起点。

当然，在系统演化的过程中，我们要考虑模块化和组件化，这是走向微服务之路的必要保证。一个组件的关键属性，是具有独立更换和升级的特点，想象一下，能够在一个点上重写该组件，而无须影响该组件的其它合作组件，是一个考虑组件是否独立更换和升级的好方法。

专家们对使用微服务采取谨慎的态度还有另外一种考量，那就是一个团队的技能因素——新技术往往会被技术过硬的团队所采用。对于技术过硬的团队而更有效的一项技术，不一定适用于一个技术略逊一筹的团队。一个糟糕的团队，总会构建一个糟糕的系统——不管是单体架构的应用，还是微服务架构的应用。

可见，不管是什么技术和工具，使用它们的人至关重要。提升自己、提升团队的能力，是保证正确地做事的关键。

 

聊聊我对微服务的看法(代码片段)

...什么说千人千面的微服务呢，这个大家和身边的人聊聊就知道了，一说大家都知道，再仔细一聊才知道大家说的不是一个微服务。我也看过很多文章，本文也可以说是这些文章的读后感o(￣︶￣)o，我比较推崇老马的这个描述。... 查看详情

阿里，京东，淘宝，美团，那些你不知道的事儿

B2B即businesstobusiness，2是to的谐音，即企业与企业之间，商家与商家之间，通过互联网进行产品、服务及信息的交换。交易的供需双方都是商家（或企业、公司）。如：阿里巴巴就是这种模式的一家公司。 B2C即businesstocustomer，... 查看详情

那些你不知道的炫酷导航交互效果(代码片段)

基于上次发布的那些你不知道的炫酷按钮交互效果反馈比较好，后续将继续收集那些炫酷的交互效果，希望可以给你的项目添砖加瓦，更上一层楼。那些你不知道的炫酷交互效果系列：那些你不知道的炫酷按钮交互效果那些你不... 查看详情

springcloudzuul那些你不知道的功能点(代码片段)

本文摘自于《SpringCloud微服务入门实战与进阶》一书。1./routes端点当@EnableZuulProxy与SpringBootActuator配合使用时，Zuul会暴露一个路由管理端点/routes。借助这个端点，可以方便、直观地查看以及管理Zuul的路由。将所有端点都暴露出来... 查看详情

关于单元测试你不知道的那些事

查看详情

关于单元测试你不知道的那些事

查看详情

关于单元测试你不知道的那些事

查看详情

你不知道的事---sringcloud的feign的继承特性(代码片段)

前言说起SpringChoud的feign大家用过的都说好。Feign是Netflix开发的声明式、模板化的HTTP客户端。对于我们微服务来说，微服务之间的api调用，使用feign来说是再方便不过的。本文先介绍一下，传统的feign的调用写法方式，再介绍我们... 查看详情

那些你不知道的炫酷开关交互效果(12种)(代码片段)

本文将继续更新那些炫酷交互效果系列文章，今天带来的是有关toggle开关相关的组件。以下是本次文章涉及到的开关组件总览图，总计收集12款不同交互效果，相信总有一款适合你。那些你不知道的炫酷交互效果系列：那些你不... 查看详情

微服务架构特性

...微服务可独立运行在自己的进程里；2、一系列独立运行的微服务共同构建起整个系统；3、每个服务为独立的业务开发，一个微服务只关注某个特定的功能，如：订单管理、用户管理等；4、微服务之间通过一些轻量的通信机制进... 查看详情

你不知道的软件测试那些事？

　你不知道的软件测试那些事？　　一、写在前言　　作为开发人员，我们都知道我们应该测试我们的代码。我们应该写单元测试，但这也通常是我们发现没时间时跳过的第一步。　　作为团队的领导者或者管理者我们都知道测... 查看详情

你不知道的rabbitmq集群架构全解(代码片段)

你不知道的RabbitMQ集群架构全解RabbitMQ系列文章RabbitMQ在Ubuntu上的环境搭建深入了解RabbitMQ工作原理及简单使用RabbitMQ交换器Exchange介绍与实践RabbitMQ事务和Confirm发送方消息确认——深入解读使用Docker部署RabbitMQ集群你不知道的RabbitM... 查看详情

字符串，那些你不知道的事(代码片段)

 Everythingyouthoughtyouknewaboutstringsiswrong.也许你会诧异，字符串有什么难的，即便遇到乱码的情况随便Google下就能找到解决方法，但是这样你不觉得有种被动的感觉嘛，我觉得和学习任何东西一样，学习编程首要是学习其思想，... 查看详情

springcloud构建微服务架构消息驱动的微服务（消费分区）dalston版

...于一些特殊场景，除了要保证单一实例消费之外，还希望那些具备相同特征的消息都能够被同一个实例进行消费。这时候我们就需要对消息进行分区处理。使用消息分区在SpringCloudStream中实现消息分区非常简单，我们可以根据消... 查看详情

解析微服务架构：融入微服务的企业集成架构

...绍融入微服务的企业集成架构的演进，并描述交互式系统的微服务模式及相关技术决策，然后给出了一个具体的微服务架构业务应用的例子。 交互型系统(SystemofEngagement)与记录型系统(SystemofRecord)随着移动互联网的快速发展， 查看详情

那些你不知道的kotlin冷知识(代码片段)

Lambda表达式Lambda固然好用，但是你知道Kotlin是如何实现的吗？kotlin代码funfoo(item:Int)=print(item)转换为java字节码@NotNullpublicfinalFunction0foo(finalintitem)return(Function0)(newFunction0()//$FF:syntheticm 查看详情

[javascript实践篇]——那些你不知道的“奇淫巧技”

1.空(null,undefined)验证刚开始，我是比较蠢的验证（我还真是这样子验证的）if(variable1!==null||variable1!==undefined||variable1!==‘‘){letvariable2=variable1;}大哥教会了我这样子验证，你会惊叹一下的letvariable2=variable1||‘‘;如果你不信，在谷... 查看详情

物联网通信技术，那些你不知道的事

...本文分享自华为云社区《物联网通信技术之有线通信技术那些你不知道的事》，原文作者 查看详情