有大佬了解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。
我认为，微服务不单单是一种技术架构，也涉及到了管理、组织架构。大多数的公司，需求、开发、测试、运维都是独立的团队，这实际上是有悖于微服务快速迭代的思想；在微服务的架构下，一个服务应该是由一个团队全权负责的。不过组织架构方面的事情，真的不是我们能说了算的。必须要用微服务？我觉得没有必要为了微服务，而微服务；有的公司把服务拆分，但是数据库依然是同一个库，依然是一个项目直接掉另外一个项目的接口，然后对外就宣称完成了微服务的改造...架构设计还是要根据需求背景、团队开发能力、软硬件实力综合来考虑。
java微服务日志处理的最合适方案是什么？
情况及需求描述：1.java spring boot开发的微服务有多个，每个微服务在4台云服务器上部署4个节点2.有1个网关，部署在一台服务器上，所有请求都通过网关进行转发和负载均衡3.需要对网关发起的每一请求都记录日志，例如请求的时间、ip、参数、耗时、返回结果等4.网关的访问日志需要保证安全持久化，即不能丢失，以便后期对账5.希望网关的访问日志的保存，能够具有一定的实时性，以便后台能够即时看到访问的变化、做数据分析等6.每个微服务、节点上的错误日志能够远程访问查看，而不是登录每一台与服务器去查日志文件7.一共有4台云服务器，2台阿里、2台华为，每台双核16g，数据库只有一个阿里的rds和redis尝试方案1：在网关配置logback，将访问日志输出到logstash，再由logstash输出到elastic，最后kibana展示，即ELK方案问题：1.logstash的过滤器grok配置有点难，默认如果log.info(RequestModel)这样打日志，RequestModel中的信息会在logstash中单独以一个"message"字段进行保存，这对后面kibana写过滤表达式很难处理。
java微服务开发最适合使用spring boot吗？
那今天就不谈微服务是使用Dubbo还是Spring Cloud，也不讨论是使用RPC还是Restful API，只单独说一说为什么大多数的Java微服务会使用Spring Boot。文中会有不少我个人的主观看法，如果大家有不赞同的地方，可以留言讨论。首先，需要了解一下为什么需要做微服务。微服务架构是将整个应用程序分割成更小的独立的服务，每个服务实现了一组独立的功能，微服务通过API暴露自己的功能实现，再通过服务治理和服务编排等，完成系统的完整功能。
每个服务都是独立并且微小的（其实这个【小】是很有争议的，不在这里展开讨论），一个微服务由一个团队负责管理，包括需求、开发、运维，可以自由选择技术，不过要求遵守一定的规范；每个微服务都需要快速迭代和部署；总的来说，微服务架构突出了一个【快】字。那么在回到题目中的问题，微服务的开发是否适合使用Spring Boot。
个人认为，答案是肯定的，Spring Boot适合使用在微服务的架构中。Spring Boot在最初设计的初衷，就是为了简化Spring应用工程的搭建，其实Spring Boot并没有引入什么新的东西，本质上它是在Spring和第三方框架的基础上进行了整合；Spring Boot通过定义的注解替代了xml配置文件，内嵌应用服务器；“约定大于配置”的思想；总之，Spring Boot让服务的搭建、开发、部署、认证鉴权、监控都变得更加的简单。
所以结合上面两点，微服务注重项目粒度的划分，一个项目会被分成多个子项目，子项目（微服务）之间独立部署并通过协议进行数据交互，每个微服务都需要【快速】的迭代和部署；而Spring Boot的最大特点就是让应用开发过程变得【更快】，因此在微服务架构中，Spring Boot是非常适合的。当然开发框架只是【快速】开发的一部分，微服务框架也不是单指应用服务的微和快，举个例子来说，如果你们的技术团队依然是需求、开发、测试分开的，每一次业务提了需求，需要需求人员进行需求评审，然后给开发人员讲解需求，开发人员开发完成之后，部署测试环境，测试人员开始进行测试；测试通过之后，提交上线申请，找一个上线节点，运维人员部署开发环境...这样是快不起来的...我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
Java后端微服务开发，为什么要单独把api模块分离出来？
不单单java提倡后端api单独模块拿出来调用，现在编程语言同样都提倡如此。那么，我们为什么要这样做呢？有什么好处吗？首先，我们说说目前对于web应用有哪些使用场景。一般而言，一个web应用，必定有个后台管理，其次可能会有门户网站，或者小程序，或者h5，再或者安卓和iOS。这么多端，这多的对接，如果我们每套都做对应接口那后端人不烦死了？所以我们会想着方便，统一用一套标准，这个就是所谓的前后端分离。
这样下来我们后端开发就可以省很多时间。可以做更多其他事情。前后端分离可以起到程序不必过于依赖某一块代码，咋们写的程序看起来也不会太过冗余。评判一个代码写的好坏，我们会从代码的简洁，可复用的程度，变量命名是否言简意赅等。所以努力做个优秀开发者，不要只做码农，好好创造，你是最优秀的程序员哟。觉得我说的还马马虎虎的，给个关注。
