研究微服务，得出我的大服务架构

之前一个完整的系统，整个系统是一个整体

一个数据源 = 一个数据库实例下，一个数据库；一切思路很简单，没有什么问题；事务也是在同一个数据库里，外键 事务 这些都很简单；

微服务时代要求拆分，假如顺应微服务时代的思路来拆分

可以看到挺复杂的，我这只是举个例子，实际上服务的拆分，并不一定要按上面的例子来拆分；这有点像Java Spring 的Bean，或delphi 的 bpl，c#的dll，但是这些语言层面的拆分 最终是运行在一个exe之中，是运行在 一台物理机器上；微服务 真的也能运用这种思想？？？

那么这样拆分后，存在什么问题呢？

总之，这个世界上有问题，就有解决方案；有2类程序员：一类是喜欢简单的问题复杂化；二类是喜欢复杂的问题简单化，我认为一个程序员是否是一个优秀的程序员，关键点 就是对美 这个字的理解，真善美里的 真和善 都好理解，美是一种哲学，这个不太容易学习，往往是天生的，厉害程序员 通常是把复杂的问题，简单化，微服务会有那么多的挑战和问题，我们应该思考 有必要使用微服务吗，而不是为了微服务而微服务一直下去，虽然所有问题都有解决方案，但根据热力学第二定律，熵值会越来越高，由于微服务注重个人价值，那么混乱程度 将指数性上升，熵值会越来越大，最终 会变成一坨屎；这也是很多大公司 又开始 反对微服务了，开始把微服务合并，开始裁员；

微服务的缺点主要包括以下几个方面：

1. 运维要求较高：微服务架构需要管理多个服务单元，每个服务单元都需要独立部署、监控和管理，这增加了运维的复杂性和成本。

2. 分布式的复杂性：微服务架构是一个分布式系统，服务之间的通信和数据一致性保证变得复杂。分布式通信大大增加了功能实现的复杂度，并可能伴随着定位难、调试难等问题。

3. 接口调整成本高：在微服务架构中，服务的接口定义变得尤为重要。一旦接口需要调整，可能涉及到多个服务的改动，成本较高。

4. 学习难度曲线加大：微服务开发需要掌握一系列的技术栈，包括服务发现、配置管理、容错处理、负载均衡等，这增加了开发人员的学习难度。

5. 数据一致性难以保证：由于微服务架构中的服务是独立运作的，保持数据一致性成为一个挑战。可能需要使用分布式事务或基于事件驱动的架构等复杂的技术手段来实现数据一致性。

6. 安全性问题：微服务架构通常涉及多个服务之间的网络通信，这可能会带来数据泄露、劫持、拒绝服务等安全问题。需要针对每个服务实施适当的安全措施来保证系统的安全性和可靠性。

7. 多服务运维难度：随着服务的增加，运维的压力也在增大。需要构建自动化的部署流程、进行有效的配置版本管理以及实施DevOps等，这些都是微服务架构面临的挑战。

8. 资源消耗：微服务架构可能导致更多的资源消耗，因为每个服务都需要独立的运行环境和资源。这可能会增加基础设施和运营成本；

综上所述，微服务架构虽然具有很多优点，但也存在一些明显的缺点。在选择是否采用微服务架构时，需要综合考虑项目的实际需求、团队的技术储备以及运维能力等因素。

我们的架构

我喜欢把复杂的问题，简单化的思路来解决，降低熵值，保证系统的稳定，可靠运行，我是反对 极端微服务的；他们叫 微服务，我称之为 我的叫大服务吧；

1. 用户服务，必须单独出来一个服务；用户的注册、注销、登录、安全控制在我手中；
2. 不允许服务之间，相互调用，只允许 终端UI调用调用服务端的服务，服务A与服务B之间禁止相互调用；此举简单明了，解决微服务的很多问题；
3. 如何划分服务，宗旨是 所谓的划分服务，服务的背后就是MySQL表，那么所谓的划分服务，就是划分MySQL表了，如何划分MySQL表，宗旨是 若订单表 依赖 地址库表 依赖商品表，那么应该把 订单 + 商品 + 地址库 这3个表，放到一个数据库（即一个数据源）里；后来又发现 购物车表也依赖商品表，那么应该把购物车表也放进来；直到所有的依赖都放进来为止；最终 会形成一个熵值很低的划分；比如：工资系统、电商综合系统、门店系统、等等 会形成 这类 互相完全无关联的服务；熵值很低，利于维护；

画图一下吧：

这个是我所需要的，一套系统 管理所有系统，不过度细分；只保证每个服务 不会调用 其它服务就可；举例：代码管理系统，根本不可能调用电商的需求，工资系统也没有调用 门店系统的需求；保证一切都是 终端UI 发起调用；只需要把 用户服务这个中间层单独出来就可；

所有的系统都依赖用户服务，而用户服务 是我控制的，是基本不会变化的，是不需要联合事务的，根本就用不到 分布式 事务；不存在 新增一个用户 时，需要联合其它服务来做分布式事务，不存在这个需求，用户服务是最基本的；

这样，一切问题 就从根基上解决了，微服务带来的负面问题，基本全部不存在，整个系统 稳定运行，熵值很低；利于维护；