认识达内从这里开始

随着互联网的不断发展，越来越多的程序员都在学习微服务等新兴互联网技术，而本文我们就通过案例分析来简单了解一下，企业微服务化技术应用分析。

一、大而集中式的服务

从0到1的堆砌式发展

一个服务承载所有，一个系统涵盖一切，这可能是大多数公司初创时的技术风貌。一切追求快速验证，快速响应，快速实现。

但是，伴随着业务的膨胀发展，相应的技术支撑要求也在不断提升。从开始的一个简单的服务，不断地添枝加叶，各种各样的功能模块相继被堆砌式添加上去。慢慢的服务开始变得臃肿，繁杂。功能模块间相互交织，耦合，混乱不堪。

同一个服务模块可能会在多个地方被不同方式的使用;

一个数据可能被存多张表中，并且数据经常不一致;

修改一个功能却不小心影响了其它功能;

一个小小的变动却要重新上线整个服务，造成大量功能抖动;

想要集成某些新特性，却因为现有繁杂的无关依赖冲突所扰;

每个新来的人员都要都要花费大量时间去熟悉，梳理整个系统的面貌;

面对新的业务需求支撑，往往捉襟见肘。

......等等

二、微服务化需要做哪些事情?

1、明确界限

直接的问题就是，你要把整个集中式的大服务拆成哪几个服务?

这并不是一个容易的问题，它不仅仅是技术方面的问题，更多的要考虑到业务的界限。

比如，对于一个社区，可以基本的划分为用户、内容两块儿。

用户模块可以继续分为用户基础、访问、设置、权限等。

内容则可以继续细分为内容、审核、推荐、搜索等。

业务大了，每一块儿都会成为一个体量服务应用。

2、依赖定序

在明确了服务界限之后，就要进一步明确当前服务的脉络结构、流程链条、依赖关系等。

哪些是上游服务?

哪些是支持性的服务?

哪些是核心服务?

哪些是基础的服务?

哪些是业务性不强，单纯地功能性依赖服务?

哪些是对外依赖小的服务?

哪些是非核心却耗资源的服务?

......等等。

好了，知道了这些，我们就可以确定一个服务拆分的先后顺序。当然，顺序没有固定原则，每个公司可以根据当下的实际情况去调整。

一般来说，基础的服务是依赖多的，也是相对核心的，这个会作为一顺序去拆解出来。比如，对于用户模块的用户信息服务，内容模块的内容服务等。后续的拆解的服务也可以此为基础，避免再去依赖旧服务。

另外，对于业务关联不强的服务，如短信，推送、图片等，也可以同步进行。尤其是对于图片、推送这些存在相对集中式耗费网络资源的，应该优先分离。

三、服务架构

架构需要考虑什么?

用什么?什么能支撑?能达到什么样的效果?

1、基础框架

什么是框架?

它是一种助力、一种经验总结的高效支持。

就像八股文，明确的行文格式(开篇、收尾、字数等)，只需要往里填充内容就是一篇合格的八股文。

2、交互

微服务化后面临的直接的问题是：服务间如何交互?

交互，其实无非两种方式：接口、消息。

两种方式不是只选其一，实际应用中，不同场景，往往需要结合使用。

3、治理

微服务化后，整体服务的复杂性由服务本身上升到了网络层。

服务不可用怎么办?

接口调用超时怎办?

消息丢失、重复怎么办?

流量突增怎么办?

服务链路怎么链接起来?

此时，你可能需要了解：服务注册发现、负载均衡、熔断降级、流量控制、服务重试、服务监控、版本管理、分布式配置中心、链路追踪、分布式日志系统等等一系列问题。

四、实施

抛开框架、结构层面的东西，其实直接关系的是业务逻辑的迁移。而在这一点上，仔细、审慎则尤为重要。缺了、漏了、变更意图都是不能容忍的。

静态代码自检、共检+动态流量快照逻辑验证可以作为基本遵循的原则。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。