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