think

https://github.com/crossoverJie/Java-Interview Java-Interview

https://github.com/aalansehaiyang/technology-talk?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io Java生态
https://github.com/xingshaocheng/architect-awesome

服务注册，路由网关，，负债均衡，断路器，配置中心

https://github.com/twitter/

kafka 分布式系统： https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying

A Distributed Systems Reading List http://dancres.github.io/Pages/

Java核心技术36讲

Designing Data-Intensive Applications http://martin.kleppmann.com/ 作者

ebay bosql design https://www.ebayinc.com/stories/blogs/tech/practical-nosql-resilience-design-pattern-for-the-enterprise/

当在一台机器上编写多线程代码时，我们有相当好的工具来实现线程安全：互斥量，信号量，原子计数器，无锁数据结构，阻塞队列等等。不幸的是，这些工具并不能直接转化为分布式系统操作，因为分布式系统没有共享内存，只有通过不可靠网络发送的消息。
​ 分布式系统中的节点，必须假定其执行可能在任意时刻暂停相当长的时间，即使是在一个函数的中间。在暂停期间，世界的其它部分在继续运转，甚至可能因为该节点没有响应，而宣告暂停节点的死亡。最终暂停的节点可能会继续运行，在再次检查自己的时钟之前，甚至可能不会意识到自己进入了睡眠。

因此传统机制（认证，访问控制，加密，防火墙等）仍然是攻击者的主要保护措施。

Microservices for Java Developers
Production-Ready Microservices

https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ 微服务

CPU时间、内存、磁盘空间或网络带宽。

微服务选型： https://mp.weixin.qq.com/s/n3SwFjSXR2hvO50Ulbs51Q

GitHub：https://github.com/pavansolapure/opencodez-samples

意味着，新旧版本的代码，以及新旧数据格式可能会在系统中同时共处。系统想要继续顺利运行，就需要保持双向兼容性：
向后兼容 (backward compatibility)
​ 新代码可以读旧数据。
向前兼容 (forward compatibility)
​ 旧代码可以读新数据。
向后兼容性通常并不难实现：新代码的作者当然知道由旧代码使用的数据格式，因此可以显示地处理它（最简单的办法是，保留旧代码即可读取旧数据）。

Servlet工作原理解析

需要注意数据库级别以确保数据库设计始终如一
向后兼容以避免破坏变化。

https://www.java-success.com

https://github.com/1c7/crash-course-computer-science-chinese 计算机video

在实际的应用场景中，Zipkin可以结合压力测试工具一起使用，分析系统在大压力下的可用性和性能

大多数大型微服务实现都有一个支持生态系统
到位。 生态系统功能包括DevOps进程，集中日志
管理，服务注册，API网关，广泛的监控，服务路由，
和流量控制机制。

微服务监控比起传统应用的监控，最明显的改变就是视角的改变，我们把监控从分层+机器的视角转换成以服务为中心的视角，
在微服务的视角下，我们的监控可以分为指标监控、链路监控和日志监控，在开源社区，这些监控也都有对应的解决方案，
比如指标监控有 prometheus、influxdb，链路监控有 zipkin、pinpoint，日志则有 elk。

断路器
断路器模式常用于确保在发生故障时，故障服务不会对整个系统产生不利影响。如果对故障服务的调用量很高，而且对于每次调用，都必须等待超时后才能继续操作，则很可能出现这种情况。调用故障服务并等待，这会使用大量资源，最终导致整个系统变得不稳定。断路器模式的行为类似于家用电气系统中的断路器。它通过"跳闸"（关闭）来保护您。对微服务的调用包装在一个断路器对象中。当服务出现故障时，断路器对象允许继续调用该服务，直到失败尝试次数达到特定阈值。此时，该服务的断路器会跳闸，任何后续调用都被短路，不会再调用故障服务。此设置可节省宝贵的资源，保持系统的整体稳定性。

隔板
船上的船体由多个不透水的隔板组成。这么做的原因是，如果一个隔板损坏，故障被限制在该隔板内，因而不会导致整艘船沉没。这种将故障隔离到系统的很小部分中的分割方法也可用在软件中。服务边界（也即微服务本身）被用作隔板来隔离任何故障。将功能（就像 SOA 架构中所做的一样）拆分为不同的微服务，可以将故障的影响隔离在一个微服务中。隔板模式也可应用于微服务内。举例而言，考虑使用一个线程池来访问两个现有系统。如果一个现有系统开始变慢并导致线程池被耗尽，那么对另一个现有系统的访问也会受到影响。拥有分开的线程池可以确保一个现有系统变慢仅会耗尽它自己的线程池，而不会影响对另一个现有系统的访问。

当用户从浏览器向服务器发起一个请求，通常会包含如下信息：http://hostname: port /contextpath/servletpath，hostname 和 port 是用来与服务器建立 TCP 连接，而后面的 URL 才是用来选择服务器中那个子容器服务用户的请求。
downstream

VisualVM Launcher

http://www.linkedkeeper.com/detail/blog.action?bid=1131&hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

rebase in process
https://stackoverflow.com/questions/29902967/rebase-in-progress-can-not-commit-how-to-proceed-or-stop-abort

interview
http://www.linkedkeeper.com/detail/blog.action?bid=1131&hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

Let me suggest that data structures and algorithms are central to any kind of development job - but not the way people seem to think of them as “magic sauce.” It’s not about trees, linked lists, etc., or about different kinds of sorts - what matters is domain & application specific. Those are so basic as to be irrelevant in any meaningful interview.

Most software is about the storage & manipulation of data - be that financial data, sensor data, molecular models, transit schedules, game state, or whatever.

How one represents and stores data - i.e., data structures, and how one manipulates it - i.e., algorithms, are very specific to different subject matter domains,
and specific applications. If you’re reducing high volume sensor streams, you organize and process data very differently than
if you’re dealing with bank accounts, or modeling protein folding.

In any meaningful interview, folks will be interested in data structures & algorithms specific to the work at hand. Know the company,
their markets & application domains, their products, and relevant software architecture approaches.

At least, that’s how I interview people, and what I expect when I’m being interviewed.

I'd suggest spending time over several months reviewing and implementing some core algorithms and data structures. I'd try to hit at least the following:

Binary search
Depth first and breadth first search
Simple dynamic programming/memoization
Dijkstra's shortest path algorithm
Mergesort and/or quicksort and radix sort
Code singly/doubly linked lists
Simple binary search tree, but also read up on red/black trees and AVL trees. Bonus points for implementing one.
Binary heap
In addition, make sure to know the relevant runtime complexities of the various algorithms. Understanding these will help you become a more valuable asset.

BFS/DFS/matchings/shortest paths/spanning trees/greedy matroids/flows/convex hulls/number factorizations/segment trees/treaps/knapsacks/KMP…

Study for interviews as much as you study class

Tech interviews are hard, so you’re going to have to study and prepare for them.

I personally say prepare for them like you would for another class.

Get a textbook.
Do practice problems.
Study everyday, every other day.
One thing to note is that not all companies you interview with will give you a tough tech interview.

But I believe if you prepare for the worst, the easy will be easier.