网易灵犀二面

下文中，我说的可能对，也能全不对，还请君自辩

不定期更新，点赞收藏关注不迷路～

（更新顺序，先个人博客后牛客（可能懒得更））

个人博客 ： http://erdengk.top/

GitHub： https://github.com/erdengk

牛客主页 ： https://www.nowcoder.com/users/2673318

----

总结：全程扣实习和项目细节，0八股，算法打家劫舍1

信号不好，站着面了一半

……………………………………

自我介绍

你对实习的期望有什么预期吗？有什么实习目的吗？

你对实习的动机是？工作内容是倾向于业务/基础研发？

讲下GSoC

讲下做的工作

讲下集成测试流程

网关底层了解过吗

hystrix 底层了解过吗

实习遇到的问题

讲下分布式的那个项目

他说可以讲cap，我就开始吟唱了

cap-pacelc-nwr-paxos-活锁

脑裂

raft解决脑裂

写代码有用到设计模式吗？

最近有看什么书么？

DDIA 、 吴军博士的软能力

读DDIA有什么收获吗？

为什么读DDIA？

讲讲为什么做这个微服务系统

拆分微服务原则是？

2.拆分原则

• 单一职责原则： 每个微服务只需关心自己的业务规则，确保职责单一，避免职责交叉，耦合度过高将会造成代码修改重合，不利于后期维护。
• 服务自治原则： 每个微服务的开发，必须拥有开发、测试、运维、部署等整个过程，并且拥有自己独立的数据库等，可以完全把其当作一个单独的项目来做，而不牵扯到其他无关业务。
• 轻量级通信原则： 微服务间需通过轻量级通信机制进行交互。首先是体量较轻，其次是需要支持跨平台、跨语言的通信协议，再次是需要具备操作性强、易于测试等能力，如：REST通信协议。
• 接口明确原则： 明确接口要实现的内容，避免接口依赖，如A接口的改动会导致B接口的改动。
• 持续演进原则： 单体架构向微服务架构拆分过程中，无法做到一蹴而就，刚开始不建议拆分太小，过度拆分将会带来架构复杂度的急剧升高，开发、测试、运维等环节很难快速适应，将会导致故障率大幅增加，可用性降低，非必要情况，应逐步拆分细化，持续演进，避免微服务数量的瞬间爆炸性增长。

你会有一些场景会你就是某一些场景导致你会在两个服务之间去做一些数据的同时的变更吗？

然后这里 Redis 主要是用来缓存什么数据，

双写问题

怎么优化？

项目流程是？

……………………………………

打家劫舍1

……………………………………

反问

部门工作

实习生工作