商城微服务架构实例_看透微服务架构

说到微服务架构已经不是热词了，早就已经风靡于互联网 IT 圈了，作者本人也是长期基于微服务架构下进行应用架构设计、实施，本文只关注微服务架构优缺点，同时，说说那些才是真正的痛点，至于什么是微服务架构和微服务架构由来不是本文讨论的重点。

单体应用架构-结构图

微服务架构-结构图

微服务架构也不是拍脑袋一下想出来，说的好听的是演进，也是被逼出来的，准确的说是从传统的单体应用拆分而来的，先说说微服务的有哪些好处呢？

微服务架构的优点：

1. 系统间相对独立：系统之间相对独立，各个子系统的发布或者故障异常，不会影响整个系统不可用。

2. 业务的切分：降低了单个系统的复杂性，各个团队按业务进行划分，各自负责独立子系统(建议按领域模型进行划分)。

3. 数据的独立：各自团队负责各自系统的数据，可做到核心业务数据与非核心隔离，不会因为个别系统数据丢失，而导致整体受损。

4. 代码的独立：各自团队负责各自微服务的代码维护，互相不会影响。快速对于系统进行迭代演进、及时修复系统漏洞。

5.针对性优化：每个系统专注自身业务，做更针对性的性能优化和服务扩容，如：电商系统用户查看商品 较多，实际下单相对较少。

6. 学习成本低： 各自团队的开发人员 只需要专注自身业务领域，不用向之前了解整个系统，开发起来举步维艰，特别是新人需要投入很长时间进行业务学习和代码熟悉。

对于微服务架构优点而言，很多同学都可以侃侃而谈，即使不懂的小白也认为微服务架构是高大上的，咔咔咔拆了一堆的微服务， 作为技术人员更应该关注的微服务架构缺点，特别是高级工程师和架构师的角色。接下来说说微服务架构给我们带来哪些问题：

微服务架构的缺点：

1. 数据一致性问题：各个子系统一般采用RESTFul 或 RPC方式等交互，在网络分区情况下，可能存在部分系统不可用或请求超时，引发出分布式事务问题；

2. 增加开发成本：每系统都需要1个或多个团队进行开发、测试、构建、版本发布、部署，对于公共事务都要重复经历很多遍，无形中也增加开发成本；

3. 加大维护的难度：拆分后子系统之前交互比较复杂，一个用户请求涉及多个子系统，某个环节异常很难发现和定位，分析、关注上、下游系统整体链路，需要引入全局日志和链路跟踪方便定位问题；

4. 物理资源开销大： 每个子系统都需要各自独享对应物理资源， ，如：Web容器、数据库、缓存和中间件，无疑给整个系统带来高额成本开销；

5. 影响整体性能：单体应用架构都是本地内部调用，微服务的间通过REST、RPC等形式进行交互，其实，性能瓶颈往往大部分就是很多不合理的互相调用，还有相互调用频繁；

说到此会很多同学问什么时候采用微服务架构，以及采用微服务架构带来以上问题 如何解决呢？ 后续作者会针对以上问题进行逐个解答，并给出对应成熟的解决方案；