你们的项目真的适合微服务吗？

本文为原创资源，欢迎分享，转载。

JAVA开发大本营

前言：最近几年微服务可以说是火爆了码农界，面试几乎多多少少都会问到微服务相关的问题，仿佛程序员不沾点微服务就OUT了。身边大大小小的公司或者团队都在进行微服务的开发及改造。

    但是实际上，很多团队对于微服务并没有一个深入的了解。很多团队一上手就是微服务，但是却完全没有将微服务应有的特性给展现出来。微服务的低耦合，灵活发布等特性被整体项目给困得死死的。强行拆分，项目耦合严重。甚至可以说得上连最简单的一体化应用都不如。

    作者亲身经历了几个大型微服务项目的从零到百万并发甚至上千万并发的过程。做为实践者，希望能跟大家分享介绍一下微服务。

             

专业术语：

异构：异构也就是采用多种语言进行开发　

耦合：一个软件结构内不同模块之间互连程度的度量             

一体化应用：将多个功能进行管理整合的单体应用

微服务扑拓：是指用传输互连各个服务的微服务架构布局。

        

《1.什么是微服务》

    微服务是一种架构风格。其中，微代表体积小，而服务代表着只服务与单一功能，总结起来微服务就是，多个很小的，只服务与单一功能的最小功能单元组合而成的系统。

    一个大型的软件系统通常由多个微服务应用组成。系统中的每一个微服务都能被很好的独立部署，能够解决单体应用耦合严重的缺点，同时可以很好的提升其中某个微服务的性能瓶颈，而不用将服务器浪费在不需要性能的微服务上。同时由于每个微服务都专注于一个功能，所以能够满足越来越复杂的业务需求。

《2.微服务架构相较于一体化架构的优势》

    我们在判断是否使用微服务之前，首先我们可以了解一下传统的一体化架构的痛点与微服务架构是否解决了这些问题。

1.遇到性能瓶颈时容易造成资源的浪费

　　传统的一体化应用只能在负载均衡之后放置多个实例进行水平扩展。

　　举个例子：

　　一体化架构：一个商城系统中秒杀出现了并发的情况，这个时候，在不改变系统架构的情况下，代码级别的优化是有瓶颈的，这个时候必然需要加服务器，创建多个实例，这个是系统级别的。但是除了秒杀这一块，后台管理，商品，等功能完全不会遇到性能瓶颈，这个时候就会造成资源的浪费。

　　微服务架构：而微服务架构在事先就会将秒杀单独布置成一个微服务模块或者放置在活动模块之中，那么当性能瓶颈来到的时候，我们只需要将单个服务进行性能扩展就可以了，对其他微服务模块没有任何影响，同时减少资源的浪费。

2.不便于异构

　　一体化架构：异构也就是采用多种语言进行开发，传统的单一系统在项目开始的时候就已经被某种技术或者语言锁定，造成了如果需要更改语言，我们需要进行项目重构。

　　微服务架构：每个服务的实现细节都相对独立，服务之间耦合较低，团队可以对每个服务进行评估，根据团队的情况针对每个服务选择最合适的开发语言以及开发方案。

3.交付周期拉长

　　一体化架构：一体化架构在应用的任何更改都需要构建和部署整个应用程序。构建与部署的时间相应的较长，不利于频繁的部署，阻碍持续阶段性交付。拉长整个交付周期。

　　微服务架构：微服务架构由多个微服务功能模块组成，如果某个功能需要改变，我们仅仅需要构建和部署修改对应的微服务模块。甚至可以短时间内多次部署测试。提高了开发效率。

4.故障级联

　　一体化架构：通常在没有做业务分离的情况下，一体化架构耦合严重，很可能一个小问题会导致整个系统的崩溃。

　　微服务架构：故障隔离，耦合较低，一个服务出现问题并不会影响到整个服务。同时由于微服务有断路器的存在，当关键服务不可用或者可用性不强时，系统仍然可以正常运行。

5.技术债务

　　一体化架构：技术债务是个很严重的问题，相信每个成型的开发团队或多或少都会遇到过相关的问题。随着时间的推移，人员的变更,前期为了项目的进度，省下的技术文档，单元测试，缺少注释。这一切，都将让后来的开发者进行买单，还债，当你修改一个功能时，会影响到意想不到的地方。

　　微服务架构：微服务架构极大的避免了一些不必要的技术债务的产生，各个微服务模块单一化的职责，每个服务明确的发布接口，使得业务的耦合降到了最低。同时，易于开发、理解和维护，也可以将债务降到最低。

　　综上看来，微服务架构确实很好的解决了我们传统一体化架构一些痛点。在原有的架构基础上进行了一系列的改良。当下，也有很多公司完成了从一体化架构向微服务架构的迁移重构。那么微服务的使用又会有哪些痛点呢？

《3.微服务的使用会有哪些痛点呢》

    

    实际上，微服务从2014年开始提出就开始引爆了整个技术圈，但真正大规模应用到生产应该是2016年。那个时候整个周边都在聊微服务，仿佛不聊几句微服务就不是程序员了一样。但是在实际使用微服务以及与周围同行讨论的过程中，我们发现了微服务的很多痛点。

 

1.服务难以治理，技术天花板高

    微服务会拉高整个技术团队的天花板，对团队的技术门槛也会要求很高。随着开发的不断进行，除了最基础的服务发现、配置中心和授权管理。团队将会在分布式跟踪、熔断降级、灰度发布、故障切换等一系列微服务治理场景中遇到种种难题。给团队带来了非常大的麻烦。

 

2.微服务应用是分布式系统，由此会带来固有的复杂性。

　　

    本身上微服务就是一个分布式项目，分布式项目相对于单体项目通过语言或者进程进行调用，微服务必须处理消息响应过慢，甚至无法召回的情况。

 

3.难以测试

　

    测试一个大型的微服务应用是一件很复杂的任务，测试一个简单的单体系统，我们只需要测试他的REST API即可，测试一个微服务项目，我们最起码要启动注册中心，网关，本身的模块，以及依赖的模块。对于测试带来了很大的不便。

 

4.微服务部署，运维有点吃不消

　　部署一个微服务系统以及相关的各项自动化组件，对运维实际上是一件很大的挑战，多个服务的配置，部署，扩展，监控。同时，自动发布（jenkins），对服务做容器化（docker），包括每个服务后续的数据库一系列。运维小哥说：“臣妾做不到啊”。那么到底什么样的项目都适用于微服务架构呢？

《4.什么样的项目适合微服务》

   

    其实微服务架构并不是万能的，其实在架构设计中，微服务本身是一件奢侈品。

    在复杂度较小的场景中，一体化架构的效率明显更高，当复杂度或者业务量到了一定的程度时，单体应用的生产效率开始极速降低，这时再对他进行微服务化才是合理的，所以，一切脱离实际业务的微服务都是耍流氓。

    那么到底什么样的项目适合微服务呢，一般来说，应该满足以下几个条件的一个到两个：

　　1.产品已经稳定或者已经有明确的产品形态，明确产品的边界，因为微服务扑拓一旦形成，重构的成本超乎想象。

　　2.公司技术积累较为成熟，有微服务项目经验，开发较为便捷，开发者有足够的控制部署方法，并且高度自动化。

　　3.业务并发较大，并且集中在一个或者少量几个业务场景下，使用微服务可有效节省资源。

　　当满足以上条件一个时，其实就可以上微服务了，同时如果是准备技术积累的一些公司，建议逐步试点，然后以点破面，逐步在团队中推行微服务架构。市面上到底有多少种常见的微服务框架呢？

《5.现有的一些常用微服务框架》

Spring Cloud

　　Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。

　　　Spring Cloud有五大重要组件，他们分别是：

　　　　　服务发现——Netflix Eureka

　　　　　客服端负载均衡——Netflix Ribbon/Feign

　　　　　服务网关——Netflix Zuul

　　　　　断路器——Netflix Hystrix

　　　　　分布式配置——Spring Cloud Config

Motan

　　Motan是新浪开源的一个RPC框架，可以看做是Dubbo的量身裁剪版。也属于服务治理型框架。Motan 提供了丰富的服务治理功能和优秀的扩展能力，可以方便的基于 Motan 进行二次开发。

gRPC

　　gRPC 是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计。

Thrift

　　Thrift是一种接口描述语言和二进制通讯协议，它被用来定义和创建跨语言的服务。它被当作一个远程过程调用（RPC）框架来使用，是由Facebook为“大规模跨语言服务开发”而开发的。

Dubbo

　　Dubbo是阿里巴巴内部的SOA服务化治理方案的核心框架，Dubbo是一个分布式服务框架。其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。

    这几种就是市面上常见的微服务框架。其实，我们使用微服务框架还是需要结合实际的场景选择合适的架构与框架，总而言之，只有适合自己的，才是最好的。

                                                                       

码字不易，觉得作者写得不错的，可以在文末右下角点个在看，感谢！

本篇会收录在面试经验-原创面试干货分类中，欢迎转载，分享！！！！