在互联网行业中，成熟的公司都会有专门的技术团队开发出各式各样的产品供用户使用。对于公司内部的不同产品而言，并不是每一个产品都需要重零构建，大多数情况下都是在旧产品基础上组合拼凑，衍生出新产品。
如果说 B、C 产品都是在 A 产品基础上开发的新产品，那么意味着什么呢？
对程序员而言，这代表着继承，也可以说是代码复用。
那么，就有个问题了，如何去让 B、C 产品的代码继承 A 产品代码呢？
A 产品代码打个包嘛，每个 Java 程序员都会使用 Maven，引入下不就好了？
话是这么说，但是有个问题，A 产品的包放在哪里？不可能放中央仓库吧？这可是公司内部的产品呀！
嘿嘿，这个时候，就需要专门搭建一个存放公司产品包的仓库，去管理这些内部产品包了。（这种内部产品包被称为二方包，公司搭建的仓库被成为二方库）。
一般而言，公司内部的二方库早就有开发搭建好了，用不着新人动手，但由于罗马并不是一天就能建成的，有的公司技术部门可能刚刚创立，会存在没搭建过私服的情况，这个时候就需要我们手动动手了。
那么，下面跟随本文来搭建一个 Maven 私服吧！
Thread 命令可以查看当前线程信息，查看线程的堆栈.
直接使用thread命令将默认按照 CPU 增量时间降序排列，只显示第一页数据。
1 | $ thread |
展示当前最忙的前 N 个线程并打印堆栈：
1 | $ thread -n 3 |
[Internal]表示为 JVM 内部线程，参考dashboard命令的介绍。cpuUsage为采样间隔时间内线程的 CPU 使用率，与dashboard命令的数据一致。deltaTime为采样间隔时间内线程的增量 CPU 时间，小于 1ms 时被取整显示为 0ms。time 线程运行总 CPU 时间。注意：线程栈为第二采样结束时获取，不能表明采样间隔时间内该线程都是在处理相同的任务。建议间隔时间不要太长，可能间隔时间越大越不准确。 可以根据具体情况尝试指定不同的间隔时间，观察输出结果。
显示所有匹配线程信息，有时需要获取全部 JVM 的线程数据进行分析。
1 | $ thread 1 |
有时候我们发现应用卡住了， 通常是由于某个线程拿住了某个锁， 并且其他线程都在等待这把锁造成的。 为了排查这类问题，可以通过thread -b命令 一键找出罪魁祸首。
1 | $ thread -b |
注意， 目前只支持找出 synchronized 关键字阻塞住的线程， 如果是
java.util.concurrent.Lock， 目前还不支持。
thread -i 1000 : 统计最近 1000ms 内的线程 CPU 时间。thread -n 3 -i 1000 : 列出 1000ms 内最忙的 3 个线程栈1 | $ thread -n 3 -i 1000 |
1 | [arthas@28114]$ thread --state WAITING |
通过命令开启采样，观察一段事件后停止，输出一个 html 火焰图文件打开观察即可。1
profiler start
1 | profiler status |
1 | profiler stop |
火焰图的效果大致如下图：
图中的每个色块代表的是一个线程栈帧，色块中是该栈帧加载执行的函数以及一些采样信息。Y 轴代表调用栈的深度，调用从底部开始向上进行，顶部是正在执行的函数，下面是它的父函数，调用栈越深，火焰就越高。X 轴代表抽样数，如果一个函数在 X 轴占据的宽度越大，表示它被抽取到的次数越多，也就意味着它占用的 CPU 时间越长。
需要注意的是，图中的颜色并不重要，只用于区分不同的函数，同时 X 轴的从左到右的顺序也不重要，默认按照字典顺序排序。
我们可以简单举个例子来理解。一般在使用性能分析工具时，我们会选取一个合适的时机启动分析采样，然后等待一段时间后停止采样。假设采样时间为 20 秒，每秒采样 100 次，那么共采样 2000 次，在这 2000 次中，共有 1800 次执行的是 main 方法，其余 200 次执行的是 run 方法，同时 main 方法又调用了很多其他方法，run 方法也是，这就形成了一个从下往上的调用链，在这些调用链中，又同时会收集到每个方法采样的次数，最终形成一张火焰图。
火焰图是可以互动的，点击某个色块，该色块会被放大并占据所有的宽度，这样可以方便地查看某个函数内部的调用链信息。一般观察火焰图，就是看顶层函数占用的宽度，如果有些函数占用的宽度很大，形成了“平顶”，那么就代表该函数可能存在性能问题。当然，有时候直接观察平顶并不能快速定位问题，因为很多时候顶部的函数都是一些底层的库函数，这时候就应该先观察业务代码在火焰图中的宽度，然后再往上观察顶部的库函数来缩小范围。
从上面的火焰图发现TestController类的wl方法占据的 x 轴宽度较长，这是因为我们程序写了一个死循环到消耗了 CPU 。
1 |
|
我们写几个不同循环次数的方法，分别代表方法耗时不同，代码如下：
1 | //示例代码,timeCost是个接口 |
部署之后我们使用 trace 来查找最耗时的方法，在此过程中需要知道包名、类名，以及方法的名字。上述代码方法所在包名为 com.cctest.arthas_demo.controller，类名为 StressSceneController，所以我们需要输入如下 trace 命令：
1 | trace |
输完命令后回车，然后 arthas 程序就进入了等待访问状态。这时候访问接口 /timeCost，我们就可以看到被测程序台在疯狂打印日志，等结束之后，arthas 命令窗口便输出了各方法耗时时间，如图 3 所示：
vmtool –action getInstances –className org.springframework.context.ApplicationContext –express ‘instances[0].getBeanDefinitionNames()’
vmtool –action getInstances –className org.springframework.context.ApplicationContext –express ‘instances[0].getBean(“testController”)’ -x 3
vmtool –action getInstances –className org.springframework.context.ApplicationContext –express ‘instances[0].getBean(“testController”).ok(1)’
ognl 语法：
""主要分为三步：
1 | sc -d cn.lovike.function.osier.core.util.SpringBeanUtils |
1 | [arthas@14466]$ sc -d cn.lovike.function.osier.core.util.SpringBeanUtils |
1 | ognl -c 18b4aac2 -x 3 '@cn.lovike.function.osier.core.util.SpringBeanUtils@getBean("redisUtils").type("osier:sys:dict")' |
返回结果：
ognl -c 2e5d6d97 -x 3 '@com.it.chenyuan.business.utils.SpringUtil@getBean(“MyRedisUtil”).get(“aper_duty_rate:hwzy:1868547696917106690”)’
1 | [HASH] |
1 | ognl -c 18b4aac2 -x 3 '@cn.lovike.function.osier.core.util.SpringBeanUtils@getBean("redisUtils").exists("osier:sys:dict")' |
返回结果：1
[true]
1 | ognl --classLoaderClass org.springframework.boot.loader.LaunchedURLClassLoader '@com.example.demo.arthas.user.UserController@logger.setLevel(@ch.qos.logback.classic.Level@DEBUG)' |
请求接口没有权限的时候一般就返回401 Unauthorized。
401通常是被权限管理的Filter拦截了，那么到底是哪个Filter处理了这个请求，返回了401？
开始trace：
1 | trace javax.servlet.Filter * |
可以在调用树的最深层，找到AdminFilterConfig$AdminFilter返回了401
1 | +---[3.806273ms] javax.servlet.FilterChain:doFilter() |
随着技术的不断发展，后端领域慢慢摒弃传统的单体架构，转而开始流行微服务架构模式。
微服务中将服务按业务拆分的理念确实不错，但福祸相依，单体架构转换为微服务架构的过程中，不可避免的会遇到一些问题。
我们首先遇到的一个问题就是——如何去管理这些拆分出来的服务？
假设现在一个系统存在 A、B、C 三个应用，每个应用部署三份，则现在存在了 A1、A2、A3、B1、B2、B3、C1、C2、C3 共九个应用。
这些应用并非各为孤岛，而是彼此联系，需要相互调用，比如 A –> B –> C（ A 应用需要调用 B，B 调用 C）。
在调用的时间轴中，不得不考虑以下问题：
经以上分析，我们发现——微服务中迫切需要一个组件来管理大量微服务，这个组件一般被称为注册中心。
除此之外，我们还发现多应用中，冗余了大量重复的的配置属性，比如说：
这些属性部分重复且应用一经发布若想二次修改，则必须重启应用才能生效，另外，不同环境的各种属性配置又不一样。
那么，思考这些问题：
经以上分析，我们发现——微服务中迫切需要一个组件来管理大量微服务的配置属性，这个组件一般被称为配置中心。
那么，市面上有没有一个框架，既可当成注册中心，又可充当配置中心，两全其美的解决上面我们遇到的问题呢？
当然是有滴啦，Nacos 就可以充当这两个角色，并且其更加强大。