微服务秒杀系统毕业论文

两年前，第一次真正接触微服务的概念，但也只是简单地进行了使用，当时技术栈主要是 Spring Boot,那时 Spring Cloud 也比较流行，但是由于各种原因，并没有转向这套（甚至用 zookeeper 实现了简单的服务发现），理论上来说，用了 Spring Boot 再转向 Spring Cloud 应该是很正常的事情。当时也认为 Spring Cloud 各种理念很高级，实现上也不错，也有 Netflix 等之类的大公司背书，而且和 Spring 天然集成的，使用起来还是比较方便。当时可能觉得其他的 RPC 框架：如 Dubbo 和 Spring Cloud 相比简直差了一个档次，可能大家都认为 Spring Cloud 是未来。 从第一家公司离职后，去了另外一家公司，发现一个很奇怪的特点，这家公司的技术比较保守，基本还是十年前或者五六年前的技术架构。记得之前看过一本书上说过，技术不与时俱进，那就相当于自取灭亡，特别是技术驱动型公司，如果一直停滞不前，那就相当于你拿几十年前的武器和别人战斗，那结果自然是必然的。为什么技术要与时俱进，不是因为有了新技术就要去使用它，而是因为新技术往往可以提高业务的运转效率，同时也可以降低成本。不过在这个公司待了两个月，还是觉得有可取的地方，第一点是对代码质量的追求，由于业务的体量和特殊性（大概是亿级），所以对代码有较高的要求；第二点是对微服务整体架构的深入，虽然这个系统没有上 Spring Cloud ,甚至 Spring Boot 都没有，还是很老的一个架构，但其中微服务的思想已经有了，比如服务的拆分，服务的水平扩展，基于 Dubbo 的一些服务发现和治理，整体来说已经算是不错了，但是也总在思考，感觉还是少了什么东西。容器化和 CI/CD 后来又到了一家比较年轻活跃的公司，接触到 Docker 的大规模使用以及 CI/CD，也是在这里，形成了整个对微服务完整生命周期的理解。 Docker 其实流行也很久了， 但是真正线上使用的并没有那么多，最近随着 Kubernetes（ k8s ） 的流行，更多公司也开始关注起来。 首先为什么服务要容器化，第一点是不再依赖于运行环境，只要有 Docker 就可以跑起来，无论你是什么发行版的 Linux 系统，还是 Windows，Mac。这有点像 JVM，屏蔽底层的细节，一次编写，到处运行，用在容器上就是一次构建，到处运行。第二点是容器化可以更好的进行持续集成，由于第一点的缘故，部署一个服务容器将非常快捷，这更加适合目前 devops 的理念。 持续集成(Continuous Integration)简称 CI ,持续部署（Continuous Deployment)简称 CD,如果微服务不把 CI/CD 放在首位，那必然整个流程就是不流畅的。有些公司还是手动本地构建包，然后 上传 到服务器上跑起来，进行这样的人肉运维，人肉上线，要么考虑一下，是不是整个 CI/CD 有问题，或者根本就没有 CI/CD 。其次 CI/CD 流程要做到每次构建自动跑单元测试，集成测试，以及 API 测试，UI 测试等等，这些流程也没有自动化的话，也谈不上完整的 CI/CD。如果没有经过这些流程把包直接上传到服务器，不出问题，那应该要烧柱香，拜拜佛。 云原生应用和服务网格 云原生应用遵循 Twelve-Factor ，云原生应用是为了解决传统应用发布升级流程缓慢、架构复杂，可维护性差而提出的的一个思想集合，集中了 微服务，devops，云等多种思想。 云原生应用应用可以跑在任意一家云服务商上，也可以实现多家服务商同时使用，同时也支持公有云和私有云的混合部署，这只是它的一个特点，更多的特点还是集中在解决传统应用面临的问题，如灰度发布，不停机发布，A/B Test, 快速回滚，服务治理等。服务网格（Service Mesh）是一个比较新的概念，但是核心思想并不新。Spring Cloud 以框架的形式侵入到程序中来解决微服务的各种问题，理论上来说，应该是效率最高，最灵活的一种做法。但是侵入性太强，而且只能 Spring 这套，异构语言的系统玩不转。Service Mesh 从另外一个角度来解决这个问题，也就是 sidecar 和 proxy，这样虽然性能上有些损失，但是扩展性却是比较灵活的，将这些基础能力（服务发现，服务治理，熔断限流，监控等）下放到基础设施中，做到对应用程序透明，是一个不错的进步。写业务逻辑不需要再去和这些东西纠结，代码逻辑也变得十分明朗。同时这样也解决了异构语言系统的问题，无论什么语言，都是可以完美的工作在一起，简直是一个完美世界。但是但是但是 Service Mesh 由于还比较新，目前还不能进行生产环境使用，就拿目前最流行的 Istio 来说，目前只发布了 版本，还不能实际使用，估计 也不行，可能得 才推荐生产，所以现在就面临一个困境，Service Mesh 是一个好东西，但是我们却用不了，呜呼哀哉。 Spring Cloud 和 Service Mesh 首先两者解决问题的方式不一样，Spring Cloud 是直接的方式，Service Mesh 是委婉的方式，这可能会造就两者之后的命运。如果目前已经上了 Spring Cloud 或者其他的，系统已经具有基础的服务治理能力，先不要考虑 Service Mesh ，要先去考虑容器化和 CI/CD ；如果没有太多的 历史 负担，则是可以考虑。 总结 技术发展太快，不能停滞不前，也不能盲目追风。当年的 SSH 也只剩下了 Spring，可是有人说 Spring 只能一个季节用，但是 Service Mesh 整年都可以用，好像很有道理。最后，路漫漫而修远兮，吾将上下而求索。