高并发场景微服务实战（一）
你好，我是程序员Alan,很快乐遇见你.
说到高并发和微服务，你是不是和我一样有很多的困惑？
- 晓得微服务开发热门，但始终是在行看热闹，不晓得外面具体有哪些内容。
- 晓得高并发零碎开发常识，是获取大厂Offer的利器，可是工作中遇不到高并发的需要场景。
- 理解过微服务开发、高并发零碎开发实践，苦于没实战经验。
- 晓得单个技术点的利用，但怎么将技术交融起来有些含糊。
为了解决本人的这些困惑，将微服务架构开发体系，高并发零碎设计体系串联起来。在面对新机会时能把握住机会，在理论产品开发中，能做到胸有成竹。
我重复思考之后，决定以一个虚构的高并发场景的微服务零碎为主线，一步步将技术点串联起来，多线程 -> 高并发 -> 服务注册 -> 服务发现 -> 服务接口治理 -> 配置核心 -> 分布式事务 -> 对立网关 -> 服务限流降级 -> 性能测试等，一个点一个点缓缓啃，由点成线，由线成面， 系统性从 0 到 1 的发明一个高并发场景的微服务零碎。通过，场景 -> 原理 -> 实际 -> 压测 -> 发现问题 -> 学习常识 -> 优化零碎，周而复始。来帮忙本人更快、更深刻地了解和消化。
为了帮忙其余有这些困惑的敌人，我会一步步把本人的设计和实现过程记录下来，把散落在网络上各处的知识点整合起来，缩小大家筛选梳理这些常识所要花费的大量工夫老本。
最初我再具体说一下本人为什么要学习高并发零碎设计和微服务开发，供大家参考。
- 求职时加强技术自信。
咱们都能显著的感触到往年是互联网的寒冬，经济局势很不好。很多公司都降本增效，也就是裁员、缩小招聘的人员数量，另一方面又冀望咱们打工人能够给公司带来更大的价值。
那么对于公司来说，仅仅懂得 CRUD， 简历中不足亮点的程序员，就不如有高并发、微服务零碎设计教训和有架构能力的程序员有吸引力了。
- 晋升技术实力，减少职业转型的可能性。
- 减少职业转型的可能：
在介绍工作和工作技能时，我和敌人经常会自嘲的称本人为互联网民工、搬砖的，只会 CV 和 CRUD。这是自嘲，也是写实。因为咱们都只是公司里一颗小小的螺丝钉长期从事部分性能开发。然而软件系统是一个简单工程，只有从更高的角度统观全局，思考业务的方方面面以及将来可能的演进方向，能力深刻理解一个产品或我的项目的外在含意，而这个话语权往往把握在更高职级的开发者、设计师、架构师手中，如果把握了一套微服务架构、开发理念，减少了向更高职级降职的可能性。
- 晋升技术实力：
计算机领域里尽管知识点庞杂，但很多核心思想都是相通的。高并发零碎设计和微服务零碎开发的技术和设计思维，无论是对于初入职场的工程师还是对于有肯定工作教训的同学来说都有很大的帮忙。
- 解决工作中软件研发难题。
- 微服务：
随着公司业务复杂度和用户量的晋升，单体利用，大量性能代码沉积在一起，显得特地臃肿繁冗，开发保护老本很高。这在日常运维、降级保护时十分不便，一个小性能的变更都有可能导致整个工程呈现问题甚至宕机，如果是运行中的生产环境解体，由此所造成的经济损失或不好的社会影响，将是不可估量的。而引入微服务，能够更好的解决这一系列的问题。
- 高并发：
即便公司业务流量安稳，并不示意不会遇到一些高并发的需要场景。同样是缓存的应用，在低并发下只须要理解根本的应用形式，但在高并发场景下须要关注缓存命中率，如何应答缓存穿透，如何防止雪崩，如何解决缓存一致性等问题，这就减少了设计方案的复杂度，对设计者能力的要求也会更高。
所以，为了防止遇到问题时慌手慌脚，有必要提前储备足够多的微服务和高并发常识，从而具备随时应答可能呈现的相干需要的能力。
我想说的是，解决产品问题不应该是最终的指标，晋升技术能力和技术视线才是咱们始终不变的谋求。
- 放弃技术的前瞻性。
研发技术迭代突飞猛进，新概念新利用也是层出不穷，云原生架构、容器化运维、中台等等，都与微服务有着奥妙的关系，只有放弃技术的持续性，能力更好的学习新技术，否则会很不利于新技术的落地利用。
站在伟人的肩膀上：
- 码闻强—SpringCloud微服务实战
- 唐扬—高并发零碎设计40问
- 阿里开发者、大淘宝技术