Java早已经不是高大山的稀世珍品了，程序员也不再是高科技工作者，而被称为码农 ，为什么呢？因为Java后台的很多基础技术都已经固定了，也就是说主要你从头到尾学一遍就能会 ，淘宝双十一搞不定，但是做个普通的网站还是没问题的。而大部分公司的流量都没有那么大，大部分工作也都是简单的正删改查做需求而已，所以程序员就慢慢变成了代码搬运工，俗称码农。

虽然Java技术从几个人的小公司到阿里头条都用，但是高级程序员和低级码农的差距也是天上低下。如果要进阶我觉得有一件事是非常重要的：全面掌握Java技术栈的大部分技术，不一定每个都很精通，但是至少常见的技术都应该很清楚的。如果一起聊天时不知道redis如何缓存同步，不知道如何分库分表、不知道如何防止消息重复消费是很丢人的事。在全局掌握之后，我们可以更加深入的理解某个技术，例如JVM、多线程、Spring、分布式和微服务的相关技术等等。

那么该如何才能很好的掌握这么多的技术呢？我觉得从头到尾自己搭建一个完整的项目是个不错的主意。在公司中，很多时候我们都是在别人的基础上干活，虽然效率最高，但是经常会失去很多学习的机会，越大的公司这种情况越明显。例如经常看到线上的服务有很多配置，你知道他们都是做啥的吗？服务启动的时候加载了一堆的文件 ，你知道哪些可以去掉吗？别人建设了分布式调度中心，你用的时候只是增加了个配置，然后迁移自己的业务，活干了不少，但是你能说自己熟悉分布式调度中心吗？等等。

自己搭建项目的好处是自己要完全理解每个细节，从0开始清晰认识整个系统。坏处自然是这个项目不能涉及太多太复杂的业务内容，是个重复造轮子的过程。而在大部分工程里，业务代码占了80%甚至更高。因此我们只能说自己搭建的项目只能征服Java的高山，而不能涵盖Java的全部。

那什么项目适合自己搞一个呢？我觉得是一个简单的电商系统。四个原因，一个是谁都知道电商咋回事，但如果换成金融等系统，估计很多人名词都看不懂。第二个是几乎后台的技术，都是为了解决电商的问题而产生的，例如安全、高并发等等，而教育类，各种各样的管理系统，反而没那么高的访问量，因此对接口限流等等没有那么高的需求。第三，我们知道的网站几乎都是买东西的，电商系统在国内至少被建造过上万次了，因此很多问题都能快速找到解决方案。第四是，电商系统能搞定，其他系统几乎都不在话下，跑过一万米的人，应该不会害怕1000米吧。

所以从今天开始我们从0开始搭建一个完整的电商系统，我们会充分参考网上很多开源的、免费的系统、说明等等，不断消化吸收，不断迭代完善，融合到我们的系统中。

这个系统按照怎么样的主线来设计呢？我们的目的是为了掌握技术，而不是真正建设能买东西的网站，所以我们首要考虑的是如何合理地逐步引入各种各样的技术和解决方案。

我打算分为四个大阶段：完成一个完整微服务架构系统，然后按照单体篇、微服务篇和云原生篇三个部分深入分析技术问题。

第一阶段：构建完整的微服务架构系统

技术是无止境的，任何一个技术例如司空见惯的数据库就会有大量的细节。我们不可能什么都会，哪边界在哪里呢？我觉得首先应该将主线把握住，将常用的内容搞清楚，将常见的方案把握好，说白了就是要会用，而且要用好。因此我们会先逐步构建一个完整的微服务架构系统，在这个过程中，我们主要解决”是什么“、”怎么用的问题“。

有了主线之后，接下来就按照单体相关技术、微服务相关技术和云原生与集群相关技术来深入分析一些重要的技术原理、源码和解决方案。不过这三个阶段只是我们专门研究技术问题的类别，不一定将一阶段彻底写完再写下一个，而是会有很多交叉，最后我们将写好的文章在这里归类起来，就像我们之前整理算法一样。

我们整个工程的名字就叫OPCJ——one project conquer Java，一个项目征服Java，以后与本项目有关的都用opcj这个标记。

第二阶段：单体篇

就是面向一台机器或者一个服务的技术，搭建一个单机完整的项目，我打算在这个篇梳理以下问题：JavaWeb、VUE前端技术、Angular前端技术、tomcat原理、数据库+JDBC+连接池、 spring、SpringMVC、ORM技术、SpringBoot、报表、文件处理、图片服务、maven，swagger并在整个过程中贯穿对项目设计的理解。

第三阶段：微服务篇

就是面向常规的微服务系统的设计，就是要构建一个如下一样的完整系统，设计的技术会非常多。

例如这里会使用分布式相关技术，例如消息队列、redis缓存、nginx、服务网关、分布式调度XXL-JOB，分布式检索ES、kafka消息等等，还有以SpringCloud为代表的微服务技术、阿里巴巴的这里会重点构建几个重要的解决方案，目前考虑的有如下这些：

1. 微服务注册中心解决方案
2. 微服务认证解决方案
3. 微服务网关解决方案
4. 微服务负载均衡解决方案
5. 微服务集中配置解决方案
6. 微服务熔断限流解决方案
7. 微服务分布式事务解决方案
8. 微服务消息中间件解决方案
9. 微服务高性能缓存解决方案
10. 微服务分库分表解决方案

第四阶段 云原生篇

虽然一提到云原生就想到K8s+Docker+KubeSphere+DevOps这些，但是云原生本身不是一个简单技术，而是一种行为方式和涉及理解。凡是能够提高云上资源利用率和应用交付效率的行为或方式都可以称之为云原生的。云原生由一系列技术支撑起来的，代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

云原生是大趋势，目前Java微服务开发越来越重，集成的功能越来越多，很多都与业务本身没有关系，而云原生的目标之一就是将那些固定的工作，例如接口限流等逐步固化到基础组件中，Java只负责业务就可以了，此外还有监控、日志、部署等很多基础功能。考虑到云原生更多是一种设计思想，我们还是做一个更具体的事情，目前考虑将以下内容归到云原生里。

1. 微服务分布式日志解决方案
2. 微服务持续集成解决方案
3. 微服务链路追踪解决方案
4. 微服务实时监控解决方案
5. 微服务压力测试解决方案
6. 微服务容器化部署解决方案

上面的任务每个拓展开都涵盖很多内容，而且做的时候会进行很多细化和调整，但是坚持做下去就可以了。