认识达内从这里开始

随着互联网的不断发展，越来越多的企业都开始引入了微服务架构开发等互联网技术，而本文我们就通过案例分析来简单了解一下，微服务架构开发应用分为哪些类型。

1、跟风派

技术大环境分析，到目前为止(2023.02)技术大环境：

各大公司都在宣传微服务以及自家实践情况

各种技术媒体也发布很多关于微服务的文章

和别人讨论技术相关的架构时，必然会提到微服务架构

这样的氛围下，微服务这3个字时不时的出现在眼前，加深你对它的印象。有时会给人带来一种“幻觉”，如果自家公司技术不进行微服务的升级改造，技术就会落后于它们，对技术产生焦虑感。

这种属于“跟风派”。完全没有考虑自家业务发展情况，反正别家公司都是这么做的，我也要这么做。

2、追新派

有的技术人，在出现新的技术时，都想要在自家业务上对新技术实践一番，以此体验新的技术给他们带来的一种“技术快感”。

“我使用了NB的技术”。为了技术而技术。

我意思不是说，对新技术不追求。

对于个人而言，这是一种“活到老，学到老”的积极学习态度，是值得大加提倡。

对于公司而言，需要考虑的情况比较复杂，至少有以下3点：

新技术出现的相关背景

新技术有哪些特性

公司现阶段业务有哪些问题?新技术真的能解决这些问题吗?

这种喜欢新技术的人，可以做公司技术预研，为将来遇到合适的业务应用这种技术打好基础。

3、简历派

好多招聘java开发的，都写着一个技能要求，熟悉springcloud并使用。

springcloud是java语言的一个微服务开发技术栈大集成框架。

招聘，这也导致一些人尝试使用微服务架构，为一下次跳槽做好准备。

这种情况于个人是一种驱动力，于公司则需要三思而行。

可能会留下一堆乱摊子-遗留的“烂”代码。

4、革新派

这一派主要是在“大泥球”单体开发上遇到了种种问题，想用新的技术架构-微服务架构来解决。

“大泥球”单体的问题：

代码腐化：业务代码经过长时间的迭代，有很多重复代码。比如一个功能可能有3,4种实现。

业务逻辑交织：业务应用经过长时间发展，功能变多，业务功能里的逻辑代码可能相互引用，交织不清。

代码复杂：功能多，业务逻辑复杂，只有少数员工能理解。这也是代码腐化一种。

维护性变差：修改bug或增加新功能时，牵一发而动全身。一个bug没修好可能导致整个软件不可用。

扩展性变差：增加新功能时，牵一发而动全身。

编译发布变长：软件代码量大，编译时长变长，导致发布时长也变长。

等等各种问题。

为了解决上面的问题，就想到微服务架构。微服务架构基本的一个点：分而治之，由大化小。目的就是把一个大单体划分为各种微服务，松耦合，独立自治。

微服务的优点：

松耦合：划分为一个一个小的微服务，代码之间逻辑交织降低。

独立部署：每个划分的微服务都是一个独立的项目，可以独立部署。

编译发布改善：划分为独立的小项目，编译时长变短，发布时长相应变短。

故障隔离：由于划分为一个一个微服务，故障仅发生在独立的微服内。

可扩展性：每个服务可以独立横向扩展，也可以从应用程序中提出独立功能变成服务，扩展变强。

职责单一团队：每个小的微服务都由一个小型的高度专注的团队负责。

技术异构：每个团队可以选择适合该业务的技术。

看着微服务的这些优点，看着是解决了大单体的问题。

但是微服务自身就没有缺点吗?有的，整体架构复杂度变高。

微服务的各种缺点：

调用复杂性：单体应用是在本地调用，微服务是通过网络调用，有的还需要调用多个其它服务才能完成一个功能，其它服务不可用怎么办?

分布式复杂性：分布式数据一致性，分布式事务问题。

部署复杂性：服务变多，部署起来也变复杂。所示基础设施CICD就变得重要。

服务治理：服务出现问题，找到问题的链路变长，所以就有链路监控。还有服务隔离和容错。

测试复杂性：集成测试变得复杂，毕竟服务多。

运维复杂性：服务变多怎么定位问题?怎么保证服务稳定?

团队协调复杂：微服务划分后就涉及多个团队沟通协作了。

等等，都是技术上遇到的问题。这些微服务的缺点也需要高度注意。

如果实施微服务，那么技术基础设施也需要及时跟进。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。