《Spring Cloud Alibaba微服务实战》之为什么使用微服务

偏执的太偏执、 2022-09-04 12:57 185阅读 0赞

### 目录 ###

*   *   *  单体架构 VS 微服务
         *  SOA VS 微服务

*  一件新事物的产生，必有有一定的道理，有它自己的生存土壤，或者说能为社会解决一些“痛点”；下面可以从单体架构、SOA各自与微服务的对比和微服务的优缺点慢慢展开。

### 单体架构 VS 微服务 ###

单体架构在业务初期，功能足够简单，网站流量不大的情况下的确是个低成本又高效的方案。  
不过随着时间的推移，业务的激增，网站流量增大，单体架构程序必然会暴露出很多问题；比如：  
（1）代码复杂度高：因为所有的代码都糅合在一起，依赖紧密，可能修改一处会带来“牵一发而动全身的风险”；这无疑给新入职的“小伙伴”带来了挑战。  
（2）体积大，部署缓慢：笔者目前遇到过最大的项目打包后是500M左右，如果更新频繁，重复的打包，发布，这是一个多么“磨人”的过程。  
（3）程序出错影响服务稳定性：如果程序某个功能出现了bug，导致大量的占用系统资源（例如陷入无穷循环等）；因为是单体架构，会导致处理用户请求缓慢，严重的可能导致服务宕机。  
注意：无穷循环例子如while(true)\{\}，如果里面没有具体的耗时操作或者休眠，就相当于一直会报告给系统有事情要做，系统就会把尽可能多的时间分给它；那么就会大量占用CPU。  
（4）阻碍技术的更新：单体应用往往只能使用当前项目的编程语言和现有的框架开发，如果引入新的框架可能会不兼容。  
（5）集群扩容不合理：假设网站流量增大了，以前单个服务支撑不了。现在使用负载均衡器（一般是使用Nginx）做一个集群。现在就有两个服务了。不过这样做并不合理；因为网站流量增大只是给用户使用的功能流量增大，像管理员使用后台管理并没有什么大的变化，现在是整个扩容；服务无法结合实际业务伸缩，从某个角度讲其实是造成了资源浪费。  
（6）历史遗留问题：一般经历过几年的单体应用，都不知道经过了多少人的手了，由于每个人的编程能力和风格都不同，这就有可能出现代码“坏味道”，但是又不敢改，俗称“祖传代码”。  
回过头来看看微服务是否能解决这一系列问题；微服务是一组小服务，单个服务代码量少，启动、部署快；因为大家都是独立的进程更甚者是独立服务器运行，所以不存在一个程序出错影响整个系统；服务间可以使用不同的编程语言，又因为服务可以根据业务进行细粒度的拆分，代码易于理解，所以不管是引入新的框架还是根据业务将服务进行动态伸缩还是很方便的。

### SOA VS 微服务 ###

微服务是SOA体系结构不断演进的结果，SOA与微服务本质上都是在拆分服务，为了降低耦合，提高代码的复用性。微服务是比之SOA更突出服务独立性，是更细粒度的划分服务，比如我有一个短信服务，我可以拆分成营销短信服务、订单短信服务等等；这个拆分粒度界限没有统一的标准，需要自己去权衡利弊。  
微服务的优点  
从传统的单体架构演化到微服务，来总结下微服务有哪些优点。  
（1）代码复杂度低：根据业务细粒度的拆分成多个小服务，业务、功能清晰，代码体积小，便于理解和维护。  
（2）技术选型不被束缚：单个服务可以根据自身业务选择合适的编程语言和技术栈实现。  
（3）独立部署：服务独立部署代表着，比如修改一个后台管理服务，就只需要重新部署这个服务就行了，其他主业务不动，影响范围小，也减少了部署和测试的时间。  
（4）服务的可伸缩性：根据自身业务发展的实际情况，哪个服务承载量到达了上限，就多部署些节点，或者是增加该服务器的配置；相应的哪个服务流量小，就减少服务节点，或者降低该服务器的配置。  
注意：这里的“节点”指的是集群的节点。  
（5）错误隔离：在多个服务中，假如后台管理服务宕机了，但是给用户提供服务的程序正常运行，错误只会影响管理员操作后台，这丝毫不影响用户的体验，一句话不耽误“挣钱”。  
（6）分库变得容易：因为微服务会拆分成多个应用，每个应用可以单独去连接一个数据库，这样也能一定程度上省去分库的成本。这样一般不再需要借助像MyCat等中间件来分库。  
微服务的缺点  
微服务即使有很多优点，但也有它的不足之处。  
（1）构建微服务系统的复杂：构建微服务系统并不是简单的服务调用，要充分考虑网络延迟和网络故障带来的影响。  
（2）服务依赖：假设有A、B、C三个服务，A调用B，B调用C，C是最底层的服务。如果此时迫不得已要改动C的接口，可能B也要改动，有可能连带着A也要改动。  
（3）数据一致性问题：在微服务中，各个服务都是独立的进程。假设A服务调用B服务，在远程调用过程中，刚好遇到网络延迟，A系统收到超时异常数据回滚，可是在B系统已经将数据保存了。  
（4）接口排除故障困难：随着微服务调用链路的拉长，要定位线上问题，不得不同时查看多个服务情况。  
（5）运维和部署：要检查和监控多个服务的健康状态，快速的部署多个服务，并且根据网站负载情况实现服务的动态伸缩等等都是不小的挑战。

*  本文是《Spring Cloud Alibaba微服务实战》书摘之一，如有兴趣可购买书籍。[天猫][Link 1]、[京东][Link 2]、[当当][Link 3]。书中内容有任何问题，可在本博客下留言，或者到[https://github.com/1030907690][https_github.com_1030907690]提issues。

[Link 1]: https://detail.tmall.com/item.htm?spm=a230r.1.14.40.4d013ed4NkvyPZ&id=650584628890&ns=1&abbucket=3
[Link 2]: https://item.jd.com/13365970.html
[Link 3]: http://product.dangdang.com/29275400.html
[https_github.com_1030907690]: https://github.com/1030907690