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

喜欢ヅ旅行 2023-06-06 03:50 11阅读 0赞

##### 背景 #####

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

--------------------

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

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

--------------------

##### 普通服务第一次进化 #####

1.  慢慢地用户量确实增加上来了，单个服务确实支撑不了。弄个集群吧。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L291dHNhbmRpbmc_size_16_color_FFFFFF_t_70 1]

--------------------

##### 普通服务第二次进化 #####

1.  慢慢地用户量确实增加了很多。发现有些表每天竟然有百万的增量，要不使用一下分区表。然后把用户服务也拆成独立的服务，把用户那些表结构也拆出来形成一个独立的数据库。（拆分库，分区表，拆分服务）
2.  Redis偶尔又宕机了，应该把内存数据持久化到磁盘上。然后弄个Redis集群。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L291dHNhbmRpbmc_size_16_color_FFFFFF_t_70 2]
3.  又是分布式服务了，也需要弄个分布式锁。不然，会出现很多不合理的问题。（zookeeper实现分布式锁，或者redission实现分布式锁）

--------------------

##### 普通服务第三次进化 #####

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

--------------------

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

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

##### 小结 #####

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L291dHNhbmRpbmc_size_16_color_FFFFFF_t_70]: /images/20230601/e7d3940248494acaa1efb7137ad3a9ec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L291dHNhbmRpbmc_size_16_color_FFFFFF_t_70 1]: /images/20230601/1b16232056964c6c8d79e3d3f51345e3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L291dHNhbmRpbmc_size_16_color_FFFFFF_t_70 2]: /images/20230601/285b305dfd4843d5a858c02b41545b69.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L291dHNhbmRpbmc_size_16_color_FFFFFF_t_70 3]: /images/20230601/63e1cbc3413b47b4b5d9154d0737c963.png