JAVA微服务体系组件介绍（一湖七景）

目录

 

1. 一湖七景总体介绍   

2. 详细介绍

      2.1 代码自动生成

      2.2 日志管理

      2.3 持续集成

      2.4 联调测试

      2.5  注册中心

      2.6  监控

      2.7  元数据管理 

---

1. 一湖七景总体介绍   

     结合公司长期技术积累，本人19年正式将公司微服务体系组件命名为一湖七景，名字源于西湖的一湖十景，感觉大有异曲同工之妙，一湖奇景是整个微服务业务模块的守护神，他们守护着业务运转的稳定，能做到问题及时通知、精准定位、对系统现状合理分析，让开发实时掌握系统运转的现状。

2. 详细介绍

      2.1 代码自动生成

       这块几乎不需要做太多介绍，基本各个公司都有代码快速生成工具，能根据表结构瞬间生成对应的前后台代码，提高开发效率。

       这么多年的摸索中对增删改查、前后端联调有一点自己的认识。基础的增删改查功能多是重复的代码模块调用，这块最适合代码根据表的一键生成。前后台分离的大策路是正确的，但前后台基于接口、字段的沟通往往浪费着一个公司很大的人力资源，比如前后台联调的接口字段说明、速度不匹配时的互相掣肘。为了提高整体开发效率，本人的建议是培训后端开发人员掌握少量基础前端框架知识，至少能启动、看懂前端ajax接口调用能把自己的接口加入到前端界面，由后端人员负责前后台代码的一键生成，前端人员负责整体的布局、样式、前端架构，好处显而易见无需过多无用沟通各司其事。

      2.2 日志管理

       日志是我们定位问题、发现问题源、收集系统运行信息的重要依托点，合理利用日志能帮我们在不影响系统运行的前提下合理掌握系统运行信息，因此的日志实现的最重要的一点就是要完全与主题代码实例脱节，即使日志模块瘫痪了系统依然在稳定运行，而不要有任何的耦合关系。

        日志收集采用filebate、日志存储采用elasticsearch、日志简单的基础展现采用kibana这块应该是没多大疑问的，也是大部分小公司的共识。

        日志的传输环节可能就各个公司根据自己的业务场景、技术实力、开发人员的思想等开始分化。本人简单列举几个场景。

        场景1：日志从文件进入es的过程中无中间环节

                filebeat+logstash+elasticsearch+kibana开发即可，方便简单。在kibana中合理配置视图观察日志采集动态。

                logstash在保障数据安全、缓存应用方面有一定得局限性，为了防止数据丢失，也为了能在日志量过大时不丢失日志数据可加入kafka组件，利用kafka的强大缓存能力、高效传输能力、可推拉的消费模式给logstash供应数据。提升安全性能，技术为filebeat+kafka+logstash+elasticsearch+kibana.

        场景2：日志需要及时分析后再存入存入es

                  有些场景是我们提取到日志里的一些异常信息后，需要马上通知相关人员。或者限于磁盘空间无力存储大批量日志数据，就比如我们公司在医院部署时医院提供的空间有限，不太敢存储大量日志，就需要中间截取过滤保存到es.采用的技术为filebeat+kafka+java模块实现kafka监听+elasticsearch+kibana。

                 日志模块的东西太多了，短篇幅无法阐述明白，我会用专门的一篇来详细说明。

      2.3 持续集成

         持续集成的作用是快速部署，最基础的组件是jenkins+git+maven+Nexus(私服，存储jar包)，我们公司用的是docker部署，又加入了rancher+harbor(镜像仓库)。

         开发人员将代码提交到git的开发分支，启动jenkins就可以根据git代码路径打包成jar/image启动部署，进行开发测试，开发环境性对比较随便，因为改动频繁。测试环境就要稍微麻烦点，开发人觉感觉代码没问题时需要把自己的代码提交到持续集成系统，有持续集成合并到git的测试分支，该发版时启动测试发版经历拉取git代码、maven打包、将打好的启动包（jar/image）根据版本号上传到私服、目标服务器拉取启动包、启动完成、测试人员测试、测试通过。正式环境就相对简单，如果测试的最高版本测试通过，直接改下启动包标签就可以用作正式版本，例如p-ma:1.0.0.1是测试镜像改名为p-ma:1.0.0就可以放入正式镜像仓库了，此时p-ma:1.0.0.1，p-ma:1.0.0其实是同一个镜像，因此p-ma:1.0.0.1已经测试通过了p-ma:1.0.0无需再测。生成完正式镜像后持续集成打包的任务就结束了。剩下的就是基于正式镜像的环境部署问题了。涉及到的流程简单，但部署涉及到的点比较多，开发起来特别是与java集成还是有一定难度的，仅提供思路参考。

      2.4 联调测试

        联调时最简单的是用swagger把接口统一管理管理起来，swagger自带参数说明、接口测试功能，无需投入过多的开发。涉及到接口需要熟悉open Api标准。

         如需对接口做相关权限管理需要在gateway网管处加入自己的处理逻辑。gateway集成swagger的具体实现可参考现有网上资料。

      2.5  注册中心

        注册中心市面上最常见得有zookeeper、eureka、nacos.三者的差异性还是挺明显的，eureka、zookeeper各自因为自身的局限性市场正在萎缩，nacos作为后起只秀，借助阿里的大背景，充分避开了市面上注册中心的缺陷，使用面正在扩大。并且集成了配置中心，让配置文件的管理更加轻松。有了注册中心，模块都在此注册后，为网关、监控等提供了方便，他们只用联通注册中心就能方便的获取各个模块的位置及接口信息。从而做到对接口的权限校验、限流等操作。个人推荐注册中心这块选择nacos.

      2.6  监控

       监控包括启动模块监控、链路监控、硬件监控、数据库监控四项。

       硬件监控包括内存使用、磁盘、存货状态。数据库监控主要参考指标是吞吐量、执行时间、并发数、利用率。

       启动模块监控spring boot admin,一款完美的与springcloud结合的模块工具，能监控各个模块的实例所占的内存、状态等信息，模块的停止与启动都能通过它看到，也相对轻量。

        链路工具最见得是zipkin、skywalking、cat，本人待过的公司用过skywalking确实优秀，适合产品级的开发使用，无侵入式监控搭配优美全面的界面指标几乎可以无需开发直接使用。我放弃skywalking选用轻量级的zipkin,是因为公司小需要的无非是两点：1.调用一条链路需要多长时间 2.是否成功。作用是对高耗时的链路抓出来专门优化，对界面访问失败的链路查看原因，确保系统访问正常。基于公司简单的需要，zipkin满足了，就没花更大的力气去引入skywalking.

      2.7  元数据管理 

       元数据是对表以及表信息的管理，包括表关联关系、字段、字段属性、表数据等等。对了解系统数据量、常用表、表影响、数据追踪等有很大帮助，目前这块有产品售卖无开源代码。有谁发现了，可以留言共享。

      后面专门章节详细介绍元数据。

      书籍参考：在公司电脑上，回头补上。

本文地址：https://blog.csdn.net/xiaocai_JSP/article/details/107401663