应用服务的发展过程应该是缓慢的

背景

1. 刚开始出现任何一个的事物，不要考虑得太复杂， 这是站在软件领域来看服务应用的发展。
2. 追求尽善尽美只会让自己精疲力竭，只会给自己增添很多的焦虑。不要担心自己做的不够好，然后别人可能会嘲笑自己。先去尝试，会犯错，别人也会笑，没关系，自己进步了就行。
3. 先让简陋的项目跑起来，不要考虑得太多，什么缓存，集群，消息中间件。数据库要不要分库，要不要分区表，要不要读写分离，要不要主从模式。分布式服务了要不要弄个分布式锁。核心的服务又是单点的，如果宕机了怎么办，要不要弄个核心服务的集群。要不要弄个现在流行的微服务。要不要引入一个新技术？
4. 本身来说，考虑完备是一个非常好的优点，如果太完备了，可能就不是优点了。不是优点的原因是：这样的焦虑会阻碍自己的效率甚至会打击到自己自信心和信心。

---

普通服务就应该想简单一点儿

1. 刚开始任何一个普通的Java web服务，应该以一种最简单的方式搭建。
   
   使用一些基础开源工具快速搭建一个服务。比如常规工具，lombok,dozer,fastjson,swaager,springMVC,shiro,quartz，okhttp等等。一开始就不要想用户特别多，请求数会不会特别大，要不要搭建一个集群，这个时候就可能引入Redis缓存做一个session管理，有了集群弄个Nginx来进行负载吧。

---

普通服务第一次进化

1. 慢慢地用户量确实增加上来了，单个服务确实支撑不了。弄个集群吧。
   

---

普通服务第二次进化

1. 慢慢地用户量确实增加了很多。发现有些表每天竟然有百万的增量，要不使用一下分区表。然后把用户服务也拆成独立的服务，把用户那些表结构也拆出来形成一个独立的数据库。（拆分库，分区表，拆分服务）

2. Redis偶尔又宕机了，应该把内存数据持久化到磁盘上。然后弄个Redis集群。
   

3. 又是分布式服务了，也需要弄个分布式锁。不然，会出现很多不合理的问题。（zookeeper实现分布式锁，或者redission实现分布式锁）

---

普通服务第三次进化

1. 数据库进行读写分离。
2. 功能越来越复杂了，解耦出来的应用之间存在强耦合关系，一个服务宕机了，后面的逻辑都跑不通了，弄个消息队列。
3. 一门语言已经无法满足业务需要了，使用个gRPC来实现异构语言。
   
4. 把原来使用okhttp方式进行API访问的方式修改为消息中间件方式。并引入异构语言来丰富功能。

---

一个项目发展过程的理论认知结构。

1. 任何一个项目，没有必要一开始就考虑得非常完备。如果分析出项目的请求量并不是很多，那么直接单台服务就可以搞定的事，就不要搞得这么焦虑。即使有一些做法不是最佳的又或者出了一点儿问题，其实都没有关系的，不应该去责备自己。而自己能够做的和做得到的就是把最基础的一些知识弄好就行了。
2. 不用一开始考虑需要：使用Niginx做负载, 加入一个Redis缓存，加入消息中间，这会给一个简单的项目引入复杂度。
3. 随着时间的推移，项目的功能增加了，复杂度上来了。服务之间可能存在很强的依赖性，然后加入消息中间件。
4. 然后，慢慢地用户量起来了，发现单台服务器支撑不了的时候，加入一个Nginx。
5. 然后，加入缓存Redis。
6. 然后，防止单点服务宕机，把核心服务都做成集群的实现方式。
7. 然后，在数据库层面做，主从模式，读写分离模式，分库模式，分区表模式。
8. 然后，每个具体的服务逻辑思考到事务情况，思考到并发情况。并且在分布式环境中实现一个分布式锁。（比如使用zookeeper的方式实现或者使用Redisson工具辅助实现）。
9. 而最后的整个实现过程，都采用了一种完备或者说一个最佳实践的方式就行了。比如分布式锁的一个稳定且最佳的实现过程。集群的一个最佳实现过程。数据库做的这些优化，主从模式，读写分离模式，分库模式和分区表模式，都整理出一个最佳最完备的实现策略就行了。以及一些常规规范，抛出异常的错误码，日志，附件的最佳实践策略。

小结

1. 应用服务的发展过程应该是缓慢的，出现的问题来引导应用服务的演进。也就是把简单的项目放到线上跑，出现了问题后，在根据具体问题一步一步优化。出现问题是发展变化的内因。如果一开始就考虑到未来，就会走的很焦虑和辛苦。