为什么会产生微服务架构

用户、数据量进一步增大，单体应用的缺点会进一步显露出来，比如：

• 耦合严重、复杂度高、可靠性差 ：单体应用越来越来很多业务会耦合在一起，一但某些模块出现Bug会影响整个系统正常运行，业务代码的耦合也会形成开发人员的依赖造成新业务难以推进
• 增加技术债、部署困难效率差 ：技术债越来越多容易会造成“不坏不修“的囧境，已完成的代码难以被修改以防止系统某个地方意料之外的调用。同于由于代码量大导致应用全量部署困难
• 系统吞吐量受限、阻碍技术进步 ：单体应用难以进一步扩展使系统吞吐量受限，同时单体应用要求使用统一技术平台或解决方案，要想引入新语言或框架会非常困难

拆分

应用规模越来越大，首先遇到瓶颈的可能就是数据库系统，面对数据库压力通常我们可以对数据库做拆分把负载分担到不同的服务器上来解决，通常数据库拆分有两种方案：

• 垂直拆分：对不同的业务系统如账户、搜索、推荐系统使用不同的数据库
• 水平拆分：对于大表，比如十亿百亿级别的，进行多表拆分

数据库水平拆分与业务逻辑耦合紧密，需要具体问题具体分析，通常这是一个非常复杂的问题。后来人们引入 NoSQL、NewSQL 用分布式概念在数据库层屏蔽掉数据库的水平拆分，比如 NoSQL 的 MongoDB Sharding，NewSQL 的 TiDB。

同样的在业务层上我们也可以通过垂直拆分和水平拆分将单体业务拆成不同的服务，服务之间通过约定好的协议通信，以提高人员开发效率，实现多机部署冗余部署来提高系统可用性与吞吐量。

微服务

我们都知道微服务是一种提倡将单一服务拆分成一组小服务、服务之间相互协调、配合，提高开发效率，最终为用户提供价值的思路。说到微服务那么这里面最重要的一个问题就是服务应该怎么拆。微服务作为 SOA(Service Oriented Architecture)思想的一种具体实践我们首先想到的就是按照不同的业务系统做垂直拆分，如下图所示：

（编辑：南昌站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!