版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
背景
- 刚开始出现任何一个的事物，不要考虑得太复杂， 这是站在软件领域来看服务应用的发展。
- 追求尽善尽美只会让自己精疲力竭，只会给自己增添很多的焦虑。不要担心自己做的不够好，然后别人可能会嘲笑自己。先去尝试，会犯错，别人也会笑，没关系，自己进步了就行。
- 先让简陋的项目跑起来，不要考虑得太多，什么缓存，集群，消息中间件。数据库要不要分库，要不要分区表，要不要读写分离，要不要主从模式。分布式服务了要不要弄个分布式锁。核心的服务又是单点的，如果宕机了怎么办，要不要弄个核心服务的集群。要不要弄个现在流行的微服务。要不要引入一个新技术？
- 本身来说，考虑完备是一个非常好的优点，如果太完备了，可能就不是优点了。不是优点的原因是：这样的焦虑会阻碍自己的效率甚至会打击到自己自信心和信心。
普通服务就应该想简单一点儿
- 刚开始任何一个普通的Java web服务，应该以一种最简单的方式搭建。
使用一些基础开源工具快速搭建一个服务。比如常规工具，lombok,dozer,fastjson,swaager,springMVC,shiro,quartz，okhttp等等。一开始就不要想用户特别多，请求数会不会特别大，要不要搭建一个集群，这个时候就可能引入Redis缓存做一个session管理，有了集群弄个Nginx来进行负载吧。
普通服务第一次进化
- 慢慢地用户量确实增加上来了，单个服务确实支撑不了。弄个集群吧。
普通服务第二次进化
-
慢慢地用户量确实增加了很多。发现有些表每天竟然有百万的增量，要不使用一下分区表。然后把用户服务也拆成独立的服务，把用户那些表结构也拆出来形成一个独立的数据库。（拆分库，分区表，拆分服务）
-
Redis偶尔又宕机了，应该把内存数据持久化到磁盘上。然后弄个Redis集群。
-
又是分布式服务了，也需要弄个分布式锁。不然，会出现很多不合理的问题。（zookeeper实现分布式锁，或者redission实现分布式锁）
普通服务第三次进化
- 数据库进行读写分离。
- 功能越来越复杂了，解耦出来的应用之间存在强耦合关系，一个服务宕机了，后面的逻辑都跑不通了，弄个消息队列。
- 一门语言已经无法满足业务需要了，使用个gRPC来实现异构语言。
- 把原来使用okhttp方式进行API访问的方式修改为消息中间件方式。并引入异构语言来丰富功能。
一个项目发展过程的理论认知结构。
- 任何一个项目，没有必要一开始就考虑得非常完备。如果分析出项目的请求量并不是很多，那么直接单台服务就可以搞定的事，就不要搞得这么焦虑。即使有一些做法不是最佳的又或者出了一点儿问题，其实都没有关系的，不应该去责备自己。而自己能够做的和做得到的就是把最基础的一些知识弄好就行了。
- 不用一开始考虑需要：使用Niginx做负载, 加入一个Redis缓存，加入消息中间，这会给一个简单的项目引入复杂度。
- 随着时间的推移，项目的功能增加了，复杂度上来了。服务之间可能存在很强的依赖性，然后加入消息中间件。
- 然后，慢慢地用户量起来了，发现单台服务器支撑不了的时候，加入一个Nginx。
- 然后，加入缓存Redis。
- 然后，防止单点服务宕机，把核心服务都做成集群的实现方式。
- 然后，在数据库层面做，主从模式，读写分离模式，分库模式，分区表模式。
- 然后，每个具体的服务逻辑思考到事务情况，思考到并发情况。并且在分布式环境中实现一个分布式锁。（比如使用zookeeper的方式实现或者使用Redisson工具辅助实现）。
- 而最后的整个实现过程，都采用了一种完备或者说一个最佳实践的方式就行了。比如分布式锁的一个稳定且最佳的实现过程。集群的一个最佳实现过程。数据库做的这些优化，主从模式，读写分离模式，分库模式和分区表模式，都整理出一个最佳最完备的实现策略就行了。以及一些常规规范，抛出异常的错误码，日志，附件的最佳实践策略。
小结
- 应用服务的发展过程应该是缓慢的，出现的问题来引导应用服务的演进。也就是把简单的项目放到线上跑，出现了问题后，在根据具体问题一步一步优化。出现问题是发展变化的内因。如果一开始就考虑到未来，就会走的很焦虑和辛苦。