今天，很多C端产品要改版要升级，那么，在改版之前要搞清楚为什么要改？目标是什么？之后所有的工作都是以这两个问题的答案为导向。
随着分布式技术的发展与演进，微服务技术成为了大型分布式IT架构的必然选择。从本质上来讲，微服务是一种架构风格，将一个大型的系统拆分为多个拥有独立生命周期的应用，应用之间采用轻量级的通信机制进行通信。这些应用都是围绕具体业务进行构建，可以独立部署、独立迭代，也可能根据业务负载独立的水平扩展。微服务思想以及相关的技术为IT架构的发展带来了一系列深刻的变革。
比如在Java体系中，用于提供HTTP服务的Tomcat、Jetty，用于进程内部通讯的RxJava，用于微服务应用之间相互调用的Feign，用于访问外部系统的MyBatis、MySQL JDBC、HTTPClient，都属于这个范畴。对于多种编程语言以及种类繁多的底层框架的适配，是一项浩大的工程，一个全链路监控方案能够适配的底层框架越多，它的能力就越强大。
我们需要记住，接口调用基于单个应用接口的维度，对链路信息进行提取并展示。当一个应用的某个接口存在问题的时候，我们能迅速通过这个功能定位这个有问题的接口。
线程分析 & 内存快照
找到有问题的代码片断之后，慢调用的根本原因是什么呢？ARMS能够对应用的线程以及内存快照做进一步的分析，为使用者优化代码提供思路。
将经验输出，接受别人的检验是高层次的总结。这种输出不仅帮助了别人，对自身更是大有裨益。总结的方式有很多，包括组织分享，撰写技术文章等等。当然“日三省吾身”也是不错的总结方式。总之，多多总结，多多分享，善莫大焉！
虽然，人类的整体知识体系一直在扩张。但是就很多重要的工程细分领域，基础理论并不高深。计算机的很多重要领域，工程师有能力在有限时间内抓住核心要害。
所以平台化的最佳实践是：投入最少的资源，解决最多的问题。平台解决一切，客户坐享其成。
搞基础技术就一定很牛吗
第一类常见的问题是沟通的可靠性。从可靠性的角度来讲，沟通分为TCP模式和UDP模式。TCP模式的形象表述是：我知道你知道。UDP模式的形象表述是：希望你知道。TCP模式当然比较可靠，不过成本比较高，UDP模式成本低，但是不可靠。在沟通可靠性方面，常见错误有如下两种：
如果说性能优化能力体现的是架构师的静态思考能力，在线运维能力考验的就是动态反应能力。残酷的现实是，无论程序多么完美，Bug永远存在。与此同时，职位越高、责任越大，很多架构师需要负责非常重要的在线系统。对于线上故障，如果不能提前预防以及快速解决，损失可能不堪设想，所以在线运维能力是优秀架构师的必备技能。
