说到微服务架构已经不是热词了,早就已经风靡于互联网 IT 圈了,作者本人也是长期基于微服务架构下进行应用架构设计、实施,本文只关注微服务架构优缺点,同时,说说那些才是真正的痛点,至于什么是微服务架构和微服务架构由来不是本文讨论的重点。
单体应用架构-结构图
微服务架构-结构图
微服务架构也不是拍脑袋一下想出来,说的好听的是演进,也是被逼出来的,准确的说是从传统的单体应用拆分而来的,先说说微服务的有哪些好处呢?
微服务架构的优点:
1. 系统间相对独立:系统之间相对独立,各个子系统的发布或者故障异常,不会影响整个系统不可用。
2. 业务的切分:降低了单个系统的复杂性,各个团队按业务进行划分,各自负责独立子系统(建议按领域模型进行划分)。
3. 数据的独立:各自团队负责各自系统的数据,可做到核心业务数据与非核心隔离,不会因为个别系统数据丢失,而导致整体受损。
4. 代码的独立:各自团队负责各自微服务的代码维护,互相不会影响。快速对于系统进行迭代演进、及时修复系统漏洞。
5.针对性优化:每个系统专注自身业务,做更针对性的性能优化和服务扩容,如:电商系统用户查看商品 较多,实际下单相对较少。
6. 学习成本低: 各自团队的开发人员 只需要专注自身业务领域,不用向之前了解整个系统,开发起来举步维艰,特别是新人需要投入很长时间进行业务学习和代码熟悉。
对于微服务架构优点而言,很多同学都可以侃侃而谈,即使不懂的小白也认为微服务架构是高大上的,咔咔咔拆了一堆的微服务, 作为技术人员更应该关注的微服务架构缺点,特别是高级工程师和架构师的角色。接下来说说微服务架构给我们带来哪些问题:
微服务架构的缺点:
1. 数据一致性问题:各个子系统一般采用RESTFul 或 RPC方式等交互,在网络分区情况下,可能存在部分系统不可用或请求超时,引发出分布式事务问题;
2. 增加开发成本:每系统都需要1个或多个团队进行开发、测试、构建、版本发布、部署,对于公共事务都要重复经历很多遍,无形中也增加开发成本;
3. 加大维护的难度:拆分后子系统之前交互比较复杂,一个用户请求涉及多个子系统,某个环节异常很难发现和定位,分析、关注上、下游系统整体链路,需要引入全局日志和链路跟踪方便定位问题;
4. 物理资源开销大: 每个子系统都需要各自独享对应物理资源, ,如:Web容器、数据库、缓存和中间件,无疑给整个系统带来高额成本开销;
5. 影响整体性能:单体应用架构都是本地内部调用,微服务的间通过REST、RPC等形式进行交互,其实,性能瓶颈往往大部分就是很多不合理的互相调用,还有相互调用频繁;
说到此会很多同学问什么时候采用微服务架构,以及采用微服务架构带来以上问题 如何解决呢? 后续作者会针对以上问题进行逐个解答,并给出对应成熟的解决方案;