标签：phone 原则 公司 打开 大牛 soc service 一行代码 依赖
今天终于把JMicro全功能模块调通，并通过压力测试检证整个系统的稳定性。
查看从2018年9月的GITHUB第一个Commit到现在，刚好199个Commit，利用所有能用的业余时间终于坚持下来把JMicro微服务框架的核心模块做出来，包括RPC，RPC数据系列化，RPC监控，消息服务，熔断器，限速器，服务网关，支持浏览器访问微服务，HTTP和WebSocket及基于以上的后台管理界面。看起这些个模块都很普通，像Dubbo，Spring Clound都有并且运行得非常好，应用也已经非常广泛。但是这两者及其他微服务框基本都有以下缺点，如技术栈松散，不成整体，入门门槛高，不容易落地，这些都给使用者和入门者带来很多麻烦及困扰。
微服务流行了这么长时间，但是很多公司都徘徊在用与不用之间，不少公司派上几个技术大牛信心满满地调研一个月，结果越看越怕，最后结论是还不如打个WAR包方便快捷！ 好不容易剩下一半公司大胆地去尝试，但面对线上成百上千的服务接口，怎么拆呢，无从下手!而好不容易有几个服务终于落地运行起来了，结果第二天几个真实流量进来前端就读条不动了?而此时监控还没上，怎么办？立马一个一个JVM去看LOG（单体应用那个套路），死活找不到有价值的LOG，更不知道卡在那个服务上面，真是抓狂！最后只剩几个不差钱的公司通过一人负责一服务，运维死盯屏幕的方式把微服务“落地”。而更多的后来者重复着“前人”的脚步后退。
JMicro通解决以上困境吗？我也不敢说能，但我在设计这里面每一个模块，甚至写每一行代码，我都坚持了这个目标，如果对这个目标不利，绝对不采取这个方案。并且坚持用简单方式解决复杂问题的原则。如下截图源码对熔断器实现的核心代码，加上空行也只用316行的一个实现类，当然，这中间坚持代码或功能的高度复用的结果，在此暂不展开。
一个成熟稳定的软件系统，发现问题比避免问题更重要。所以花很大部份时间在做服务监控模块，力求在系统出现问题时，能快速发现问题。而在此之后，还会继续在服务监控，服务预警，服务智能调控等方面做开发改进，力求在这方面朝着完美靠近。
下图是后台管理的主菜单，前面3个都是与服务监控相关。
下图是SERVICE菜单下服务列表及打开其中一个服务方法的编辑器
下图是服务多维度的动态的实时的服务数据
下图是对其中的一个组件监控
以上几个截图只是其中的几个服务监控相关的前端展示，而更加能体其对于监控支持的在于其后端实现的高度可配置性及二次开发实施的高度灵活性。如服务信息上报，服务信息统计，服务信息分发，同步与异步切换，在其中所涉及数据同步与性能的灵活使用等等。
一般情况下，大而全的软件都会很复杂，比如一个Oracle商业版，听说有好几十个G，听着都恐怖，不要说去安装使用。Spring Clound则有几十个的Jar包组成一个应用，尽管很多都没用，但是往往没人敢去删，一般都是能用就行!
下面是 JMicro依赖的包，红框表示主要的包，也体现JMicro基础依赖，核心依赖相当简洁。
以下视频演示
https://v.youku.com/v_show/id_XNDY0OTY4MjE1Ng==.html?spm=a2h0c.8166622.PhoneSokuUgc_1.dtitle
Github 源码地址：
https://github.com/mynewworldyyl/jmicro
标签：phone 原则 公司 打开 大牛 soc service 一行代码 依赖
原文地址：https://www.cnblogs.com/jmicro/p/12772742.html
