、在大多数情况下，由于缺乏跨多个系统的分布式事务支持，维护数据一致性是非常具有挑战性的。开发者可能需要权衡可用性和一致性之间的关系。比如通过Event Sourcing（事件溯源）实现最终一致性，
在云原生时代又有了更多新的手段，Kubernetes 让我们可以轻松注入故障，杀死pod，模拟应用失效和自愈过程。
在架构上，Java EE 是一个大的单体应用平台，拖慢了自身架构迭代的速度，跟不上时代的变化。由于Java EE过于复杂、沉重，在微服务兴起之后已经被大多数开发者所遗忘。
定好目标后，一定要了解产品背后的数据质量。关于数据质量，公司内部、部门之间的指标定义各不相同，不过普遍存在数据不准、没有数据、数据脏乱差、易用性差等问题。如何解决？其实，数据中包含着业务需求，需求弄清楚了才会转化到埋点设计，埋点方案再转化为具体的研发。
这样的方式是极为脆弱的，开发者稍有疏忽就会导致链路信息丢失，甚至影响到正常的业务逻辑。所以非手工埋点的自动链路信息采集，成为了业界的主流，其中包括两种实现方式：
点击应用列表右上角的全局拓扑按钮，能够通过可视化界面观察所有接入ARMS应用的拓扑结构，这个界面清晰的展示了所有应用的上下游组件以及相应的调用关系，能够帮助使用者从全局角度深入理解整个微服务系统。
向老师和领导学习已经是人们生活习惯的一部分了。但是从同事甚至对手那里学习也很重要，因为这些人和我们自身更相似。所以要多多观察，取其所长，弃其所短。对于团队的小兄弟和下属，也要“不耻下问”。
先你得是行业里面的顶尖专家了——实在很难找到比你更强的人了！
其次，你经常需要承担对你自己的能力有挑战的任务，但同时你拥有一批聪明能干的队友。虽然你的技术能力最高，但是在你不熟悉的领域，你的队友能够进行探索并扩展整个团队的知识。
第二类沟通问题是时效性问题。从时效性讲，沟通分为：同步模式和异步模式。同步沟通形象地说就是：你现在给我听好了。异步沟通的形象表述是：记得给我做好了。在沟通时效性方面，有如下两种常见错误：
在线运维本质上是一个强化学习的过程。很多能力都可以通过看书、查资料来完成，但在线运维能力往往需要大量的实践来提升。
