它的优缺点有哪些,微服务的优缺点

有大佬了解Java中的微服务项目吗？

以下是国内比较火的5款Java微服务开源项目，祝你面试成功。1.pig开源地址：https://gitee.com/log4j/pig基于Spring Cloud、OAuth2.0、Vue的前后端分离的系统。 通用RBAC权限设计及其数据权限和分库分表 支持服务限流、动态路由、灰度发布、 支持常见登录方式， 多系统SSO登录， 提供配套视频开发教程功能列表：完善登录：账号密码模式、短信验证码模式、社交账号模式均整合Spring security oAuth单点登录：基于Srping security oAuth 提供单点登录接口，方便其他系统对接用户管理：用户是系统操作者，该功能主要完成系统用户配置。

机构管理：配置系统组织机构，树结构展现，可随意调整上下级。菜单管理：配置系统菜单，操作权限，按钮权限标识等。角色管理：角色菜单权限分配、设置角色按机构进行数据范围权限划分。动态路由：基于zuul实现动态路由，后端可配置化。灰度发布：自定义ribbon路由规则匹配多版本请求。终端管理：动态配置oauth终端，后端可配置化。

字典管理：对系统中经常使用的一些较为固定的数据进行维护，如：是否等。操作日志：系统正常操作日志记录和查询；系统异常信息日志记录和查询。服务限流：多种维度的流量控制（服务、IP、用户等）消息总线：配置动态实时刷新分库分表：shardingdbc分库分表策略数据权限: 使用mybatis对原查询做增强，业务代码不用控制，即可实现。

文件系统: 支持FastDFS、七牛云，扩展API几行代码实现上传下载消息中心：短信、邮件模板发送，几行代码实现发送聚合文档：基于zuul实现 swagger各个模块的实现代码生成：前后端代码的生成，支持Vue缓存管理：基于Cache Cloud 保证Redis 的高可用服务监控: Spring Boot Admin分布式任务调度： 基于elastic-job的分布式任务，zookeeper做调度中心zipkin链路追踪： 数据保存ELK，图形化展示pinpoint链路追踪： 数据保存hbase，图形化展示2.zheng开源地址：https://gitee.com/shuzheng/zheng基于Spring SpringMVC Mybatis分布式敏捷开发系统架构，提供整套公共微服务服务模块：集中权限管理（单点登录）、内容管理、支付中心、用户管理（支持第三方登录）、微信平台、存储系统、配置中心、日志分析、任务和通知等，支持服务治理、监控和追踪，努力为中小型企业打造全方位J2EE企业级开发解决方案。

3.Cloud-Platform开源地址：https://gitee.com/minull/ace-securityCloud-Platform是国内首个基于Spring Cloud微服务化开发平台，核心技术采用Spring Boot2以及Spring Cloud Gateway相关核心组件，前端采用vue-element-admin组件。

具有统一授权、认证后台管理系统，其中包含具备用户管理、资源权限管理、网关API管理等多个模块，支持多业务系统并行开发，可以作为后端服务的开发脚手架。代码简洁，架构清晰，适合学习和直接项目中使用。架构摘要服务鉴权通过JWT的方式来加强服务之间调度的权限验证，保证内部服务的安全性。监控利用Spring Boot Admin 来监控各个独立Service的运行状态；利用Hystrix Dashboard来实时查看接口的运行状态和调用频率等。

负载均衡将服务保留的rest进行代理和网关控制，除了平常经常使用的node.js、nginx外，Spring Cloud系列的zuul和ribbon，可以帮我们进行正常的网关管控和负载均衡。其中扩展和借鉴国外项目的扩展基于JWT的Zuul限流插件，方面进行限流。服务注册与调用基于Consul来实现的服务注册与调用，在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个HTTP请求。

熔断机制因为采取了服务的分布，为了避免服务之间的调用“雪崩”，采用了Hystrix的作为熔断器，避免了服务之间的“雪崩”。4.SpringBlade开源地址：https://gitee.com/smallc/SpringBladeSpringBlade 2.0 是一个基于 Spring Boot 2 Spring Cloud Finchley Mybatis 等核心技术，用于快速构建中大型系统的基础框架。

主要特性变化采用前后端分离的模式，前端单独开源出一个框架：Sword，主要选型技术为React、Ant Design、Umi、Dva后端采用SpringCloud全家桶，并同时对其基础组件做了高度的封装，单独开源出一个框架：Blade-ToolBlade-Tool已推送至Maven中央库，直接引入即可，减少了工程的臃肿，也可更注重于业务开发注册中心选型Consul部署使用Docker或K8s Jenkins使用Traefik进行反向代理踩了踩Kong的坑，有个基本的使用方案，但不深入，因为涉及到OpenResty。

封装了简单的Secure模块，采用JWT做Token认证，可拓展集成Redis等细颗粒度控制方案在2.0诞生之前，已经稳定生产了近一年，经历了从Camden - Finchley的技术架构，也经历了从fat jar - docker - k8s jenkins的部署架构项目分包明确，规范微服务的开发模式，使包与包之间的分工清晰。

5.Guns开源地址：https://gitee.com/stylefeng/gunsGuns基于Spring Boot 2，致力于做更简洁的后台管理系统，完美整合springmvc shiro mybatis-plus beetl，Guns项目代码简洁，注释丰富，上手容易，同时Guns包含许多基础模块(用户管理，角色管理，部门管理，字典管理等10个模块)，可以直接作为一个后台管理系统的脚手架！同时提供spring cloud版本！Guns微服务版本Guns的核心是roses-kernel项目https://gitee.com/stylefeng-Roses/roses-kernel，提供对spring cloud的支持。

Roses框架基于Spring Boot 2和Spring Cloud Finchley.RELEASE，整合Eureka Hystrix Ribbon Feign Zuul，更符合企业级的分布式和服务化解决方案，Roses拥有高效率的开发体验，提供可靠消息最终一致性分布式事务解决方案，提供基于调用链的服务治理，提供可靠的服务异常定位方案（Log Trace）等等，一个分布式框架不仅需要构建高效稳定的底层开发框架，更需要解决分布式带来的种种挑战！管理系统功能1.用户管理 2.角色管理 3.部门管理 4.菜单管理 5.字典管理 6.业务日志 7.登录日志 8.监控管理 9.通知管理 10.代码生成（旗舰版目前还没完成）项目特点基于SpringBoot，简化了大量项目配置和maven依赖，让您更专注于业务开发，独特的分包方式，代码多而不乱。

完善的日志记录体系，可记录登录日志，业务操作日志(可记录操作前和操作后的数据)，异常日志到数据库，通过@BussinessLog注解和LogObjectHolder.me().set()方法，业务操作日志可具体记录哪个用户，执行了哪些业务，修改了哪些数据，并且日志记录为异步执行，详情请见@BussinessLog注解和LogObjectHolder，LogManager，LogAop类。

利用beetl模板引擎对前台页面进行封装和拆分，使臃肿的html代码变得简洁，更加易维护。对常用js插件进行二次封装，使js代码变得简洁，更加易维护，具体请见webapp/static/js/common文件夹内js代码。利用ehcache框架对经常调用的查询进行缓存，提升运行速度，具体请见ConstantFactory类中@Cacheable标记的方法。

controller层采用map warpper方式的返回结果，返回给前端更为灵活的数据，具体参见com.stylefeng.guns.modular.system.warpper包中具体类。防止XSS攻击，通过XssFilter类对所有的输入的非法字符串进行过滤以及替换。简单可用的代码生成体系，通过SimpleTemplateEngine可生成带有主页跳转和增删改查的通用控制器、html页面以及相关的js，还可以生成Service和Dao，并且这些生成项都为可选的，通过ContextConfig下的一些列xxxSwitch开关，可灵活控制生成模板代码，让您把时间放在真正的业务上。

控制器层统一的异常拦截机制，利用@ControllerAdvice统一对异常拦截，具体见com.stylefeng.guns.core.aop.GlobalExceptionHandler类。页面统一的js key-value单例模式写法，每个页面生成一个唯一的全局变量，提高js的利用效率，并且有效防止多个人员开发引起的函数名/类名冲突，并且可以更好地去维护代码。

业务日志记录日志记录采用aop(LogAop类)方式对所有包含@BussinessLog注解的方法进行aop切入，会记录下当前用户执行了哪些操作（即@BussinessLog value属性的内容），如果涉及到数据修改，会取当前http请求的所有requestParameters与LogObjectHolder类中缓存的Object对象的所有字段作比较（所以在编辑之前的获取详情接口中需要缓存被修改对象之前的字段信息），日志内容会异步存入数据库中（通过ScheduledThreadPoolExecutor类）。

java微服务和分布式的区别有哪些？

这个问题已经收藏了一个多月了，一直在考虑如何回答这个问题，总结了很长时间终于有了一些感悟（之前一直都是只可意会不可言传的感觉），和大家分享一下，如果有不同的建议，欢迎大家留言指正。分布式和微服务首先 ，我认为微服务就是分布式框架的一种。分布式的思想就是把一个系统的不同模块，部署在不同的服务器上，以应对高并发的问题。

SOA是一种分布式架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合、编排实现业务流程；通常在SOA架构中，ESB企业服务总线扮演了重要的角色。微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线、去中心化，部署粒度更细，服务扩展更灵活。微服务不只是技术架构很多同学一说微服务，就说这是一种技术架构，有的推荐使用Dubbo，有的推荐使用Spring Cloud。

我认为，微服务不单单是一种技术架构，也涉及到了管理、组织架构。大多数的公司，需求、开发、测试、运维都是独立的团队，这实际上是有悖于微服务快速迭代的思想；在微服务的架构下，一个服务应该是由一个团队全权负责的。不过组织架构方面的事情，真的不是我们能说了算的。必须要用微服务？我觉得没有必要为了微服务，而微服务；有的公司把服务拆分，但是数据库依然是同一个库，依然是一个项目直接掉另外一个项目的接口，然后对外就宣称完成了微服务的改造...架构设计还是要根据需求背景、团队开发能力、软硬件实力综合来考虑。

系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？

下面简单回答下这个问题。在回答这个问题前还是先回顾下微服务架构。微服务架构概述微服务架构本质是单个业务系统彻底的组件化（前端，逻辑层，数据库）解耦，同时相互之间通过轻量的服务接口和协议进行协同。这和很早就谈到的组件化架构思想是一致的，实现微服务架构后，你会看到没有传统业务系统的概念了，有的只是微服务模块或小应用。

微服务架构最近又炒的相当活，很多人会说SOA过时了，ESB过时了，甚至还有人用微服务架构去彻底的否定SOA和ESB，这些都是相当危险的信号。在我12，13年写企业私有云PaaS平台的一系列文章的时候，已经提出了业务能力组件化，组件服务化的微服务架构思想，但是实际应用实施效果并不太理想。我们可以先看下从单体应用到微服务架构的变化图。

把这个核心搞清楚后，再来看下网上找到的对微服务架构的一些定义和阐述：微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。

如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。

如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

在了解了微服务架构后，我们来分析下微服务架构又哪些缺点和难点。微服务模块拆分后，各微服务间集成复杂度指数级增加简单举例来说，一个企业已经实施了5个业务系统，业务系统之间有10个接口。如果全部微服务化则可能设计到50个微服务模块，上100个接口和集成点。可想而知，在彻底实施微服务后，我们前期架构设计，后期集成和管控的复杂度增加10倍以上。

这种集成难度会远超大多数人想象，如果拿真实做的项目来说，如果谈业务系统只有3个，而到微服务模块级别则有接近60个，而实际涉及到的集成接口上1000个。我们做任何一个复杂端到端业务的联调基本就需要花2，3周甚至更长的时间。互联网企业为何适合做微服务架构，其重要的一个原因就是互联网企业如电商平台，在进行了微服务化后各个模块之间耦合性很低，并不会有太多的集成和协同点。

或者简单来说，各个微服务模块更多的是向上面的PC端或APP端提供服务能力，而模块横向间接口协同很少。正是在这种低耦合情况下，协同和集成相对来说容易。而转回到企业内部你会发现，在微服务模块化后，各个模块之间的集成点相当多，特别是业务系统拆分到模块或组件这一个级别后，很多原有内部的集成和依赖点全部暴露出来了，你都需要去很好的管理。

由于这里面有大量的横向集成和协同点，因此导致的就是微服务模块间的横向集成异常复杂，远超很多互联网应用，这是实际你会面临的问题。微服务模块拆分后，各微服务间集成复杂度指数级增加只谈微服务架构的松耦合和高扩展性，而不谈开发和集成复杂度的都是耍流氓。实际上当前很多企业对微服务架构并没有如此迫切，互联网很多企业推行微服务架构更多的还是考虑到巨大的业务并发量下的系统弹性扩展能力，而实际大多数企业内应用往往并没有如此海量并发。

其次，即使在并发量增加的情况下通过进行代码本身的优化，数据库调优或者升级硬件服务器资源都可以较好的解决性能问题。而做这些事情投入的成本远远小于微服务架构带来的开发复杂度增加成本，后期的运维管控成本。要做到完全微服务模块独立，微服务架构下最大的一个变化就是数据库也拆分开了，原来的一个业务系统如果分为5个微服务模块，那理论上就是5个独立的后台数据库，而且数据库间还不能随便相互连接和访问。

只有这样微服务模块才能做到独立部署和管理。由于数据库拆分带来两个问题，其一是我们原来很简单的一个跨表查询操作现在无法做了，我们必须调用两个微服务模块提供的服务，查询到数据后再到逻辑层进行组合。其次最大的问题就是如果一个业务操作需要同时更新两个微服务模块的数据，由于服务本身无状态，导致了这种分布式事务问题很难解决。

企业内业务系统很大一个特点就是业务逻辑和规则相对互联网更加复杂，而且有更高的事务一致性要求。正是由于这个原因，无法解决好分布式事务的问题都将直接导致后续数据不一致和业务错误。原来通过调用项目内一个API方法就能解决的问题，现在要调用远程WS接口才能解决，这本身就增加了开发和调试的复杂度。一个微服务模块与外部其它模块的集成和协同越少，你会发现该微服务模块和传统业务系统开发没太大区别，但是当其涉及到完成任何一个功能都需要调用外部微服务模块的服务接口时候，其开发模式和效率上就会带来巨大的变化。

微服务架构下运维难度增加在实施了微服务架构后，运维的复杂度也是成倍增加，任何一个微服务模块出问题都可能影响到整个业务应用的功能使用。我们在运维时候不仅仅要健康单个微服务模块，还需要健康所有的接口服务监控状态。如果跟Docker集成了，我们看到整个性能监控和问题分析都会变麻烦了，没有实施微服务架构前发现问题，我们直接可以看应用服务器上类似tomcat或jboss日志，而实施了微服务架构后，应用容器已经是自动部署和动态分配的，原有的故障诊断模式行不通，而需要PaaS平台本身提供完整的预警和日志分析能力。

再次，如果发现了性能问题或故障，我们的解决方案是如何的？我们如何保证不影响到业务运行，不出现数据的丢失，或者在微服务模块扩展的时候不出现业务中断等。这些已经不是简单的部署架构层面的冗余能解决的问题，而涉及到我们在整个微服务架构中的消息策略，事务管理机制，持久化机制等问题。引入微服务后的实施难度增加一个企业所涉及到的IT开发和架构能力以及企业本身的IT治理管控成熟度都将直接影响到微服务架构能否实施成功，要知道引入微服务架构后集成和后续运维等的复杂度都会成指数级增长。

方式1：引入的外部开发商进行微服务架构化如果一个企业本身IT部门规模小，软件以外购为主，那么势必在对ERP等各类软件的选型评估后引入不同的软件产品提供商或软件开发商。那么软件商本身都有了成熟的产品或架构，其产品内部的模块是否符合组件化和微服务架构的要求，我们不得而知。即使招标要求写明软件提供商提供产品需要基于SOA或微服务参考架构，但是实际上由于企业本身的IT能力和水平往往也无法验证，而对于软件厂商来说一定希望是卖现有产品，减少改造和定制实现利润的最大化。

对于软件开发厂商来说对已有的软件产品是没有微服务架构改造的动力的。那在这种情况下要推动微服务架构实施落地必须的就是企业本身有很强的架构管控能力和甲方话语权。在曾经实施的案例里面可以看到，甲方在有较强的IT规划和架构设计能力情况下，才可能一开始就划分好微服务模块并且设计好微服务模块间的接口，在进行招标和选型。

同时甲方话语权强的情况下，可以完全要求软件供应商按照自己定义好的标准，规范，架构进行微服务模块的开发。简单点来说顶层架构分解和接口设计能力不在单个微服务模块开发商手里面，而是在甲方手里，或者在甲方请的专门负责规划架构设计的技术咨询团队手里。在这种模式下，技术咨询团队应该对整体模块划分和后续集成负责，技术咨询团队就需要有业务和技术两方面的能力，同时有类似领域的规划设计经验，系统开发建设经验等。

这些本身就对技术咨询团队提出了相当高的要求，可以来讲很少有技术咨询团队达到这个水平，包括埃森哲或德勤等也难。在微服务架构下，我们希望的是一个业务系统如果由三个微服务模块组成，在我们进行了前期的架构和接口设计后，我们完全可以将三个模块发标给不同的软件开发商建设和实施，然后在根据预先定义的服务接口进行集成。

这个从理论上是行得通的，但是实际上出现两个问题。其一是刚开始的模块划分或接口设计不合理，在后面开发过程中才发现又很难再大变更。其二是微服务模块间的接口服务太多，导致了模块间的集成和联调异常复杂。从上面也看到引入微服务架构后，企业本身可以削弱单个软件供应商对企业本身的约束，防止被单一厂商绑定。因此企业没有特色要求，从软件厂商来说没有任何动力和意愿推微服务架构。

方式2：企业自由开发团队实践微服务架构如果企业本身的IT成熟度没有达到一定阶段，显然是不可能推行实施微服务架构的。这个道理前面已经谈到过，在企业IT建设中，如果连粗粒度的业务系统以及它们之间的集成都管理不好，那么更没有能力管理细粒度的微服务模块。那么如果企业IT成熟度达到一定水平，在推广微服务架构还存在的难点如下：首先是架构设计能力的显性化，即架构设计这个工作的输入，输出和过程需要更加的显性化出来形成团队都认同的标准工件。

一个业务系统没有拆分开时候，虽然有架构设计和组件划分，但是这个工作是属于团队内部的事情，即使架构设计不合理，在后期集成也可以通过诸多变通方式解决掉。而现在是不同的微服务模块可能分派到两个独立的团队开发，原来属于自己内部黑盒的问题变为团队间问题。简单来说你原来藏着或没做规范的东西太多，而现在这些不能再藏着掖着了，当真要把这些东西拿出来的时候，你才会发现你原来架构能力是有欠缺的。

正如我们理解了一个东西，那么要让我们清楚的讲出来困难，那么我们的理解有欠缺。对于我们能讲清楚的东西，要系统的写下来有困难，那么说明我们讲的结构和条理有欠缺。其次管控要求和规范体系的建立，对于管控要求可以看到如果两个微服务模块分给同一个团队开发，如何才能保证开发的团队保持两个模块的完全独立和解耦，两个模块间不会出现相互交叉的数据库直接调用，也不会存在直接绕开Service接口的其它耦合调用？这些如果没有完整的管控和检查体系我们很难约束。