2.3 用上分布式、微服务技术系统拓展性就强？

      微服务，也被称为微服务架构，是一种构建应用程序的方法。在这种架构中，一个大型应用被分解成许多独立的、较小的服务，这些服务都运行在自己的进程中，并且通过某种轻量级的机制（通常是 HTTP REST API或者消息队列）进行通信。每个服务通常都是围绕着特定的业务能力构建的，它们可以独立部署和扩展。

微服务架构的主要优点包括：

敏捷性

    因为每个服务都是独立部署的，所以团队可以更快速地开发和迭代服务，而不必等待整个应用的部署周期。

扩展性

   如果某个服务需要更多的资源，你可以单独扩展那个服务，而不是整个应用。

容错性

    如果一个服务出现故障，它不会直接影响到其他服务。这使得微服务架构的应用更加稳定，故障影响范围更小。

技术多样性

  不同的服务可以使用不同的技术栈，这给了开发团队更大的灵活性。

  然而，也是由于这些优势导致微服务技术被滥用，尤其是服务模块划分是一个具有挑战性的事情。微服务划分过度可能带来的问题包括：

   过度复杂性

   每个服务都需要处理网络通信、数据一致性、服务发现和故障恢复等问题，因此随着服务数量的增加，系统的复杂性会大幅度提升。

高网络开销

    如果服务划分过细，那么可能会导致大量的跨服务通信，这可能会增加网络开销，并可能导致性能问题。

数据一致性问题

   微服务中的每个服务都应该拥有自己的数据库，以确保服务的独立性。然而，如果服务划分过细，那么处理跨服务的数据一致性就会变得非常困难。

团队沟通成本增加

   随着服务数量的增加，团队成员需要理解和跟踪的服务和交互也会增加，这可能会增加沟通的成本和复杂性。

    因此，在划分微服务时，需要考虑到这些可能的问题，避免过度划分服务。合理的服务划分应该根据实际的业务需求、团队结构和技术能力等因素进行，而不应该单纯地追求服务的数量和独立性。

    如何划分服务，其实追究到最后还是考验的架构设计上的单一责任原则的理解问题，假如一个类的职责都订阅不清楚，一个函数的功能职责都是模糊的，那么微服务层面就将更加的混乱。面向对象设计的面向对象设计的五个基本原则，其实就已经把相关的规范给我们讲清楚了，但是少有人能够将其领悟。

五个基本原则（SOLID）：

单一职责原则（Single Responsibility Principle, SRP）：一个类应该只有一个改变的原因。

开放封闭原则（Open-Closed Principle, OCP）：软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。

里氏替换原则（Liskov Substitution Principle, LSP）：子类型必须能够替换掉它们的基类型。

接口隔离原则（Interface Segregation Principle, ISP）：客户端不应该依赖于它们不使用的接口。

依赖倒置原则（Dependency Inversion Principle, DIP）：高层模块不应该依赖低层模块，它们都应该依赖于抽象。

总结

    微服务的技术是很容易被引入的，这也导致大家更注重技术本身而忽悠业务。其实作为一个软件系统，业务才是核心，而业务通常是易变的，我们通过引入一项技术后，如果不能让业务可以更加灵活的应对需求，而只是解决部分技术问题，那这是失败的，因为这样的做法会让业务更加的被腐蚀，让业务与技术相互纠缠再在一起，这就导致业务无法聚焦、无法被复用。 

    我一直推崇的架构设计就是要把业务与技术分离，做到技术可任意更换，可任意升级，而业务则可以不断的沉淀与优化。