后端架构的演进

当前微服务架构大行其道，很多java工程师也对微服务架构的学习和使用趋之若鹜。但是对于技术人来说，比了解技术更重要的是了解技术产生的背景及核心原理。

现在看起来非常复杂和庞大的架构，一定都是随着业务产品种用户量和数据量增长而不断演进的。架构的发展可能都会经历单体架构、垂直和集群、SOA（面向服务架构）、微服务架构等。

单体架构

单体架构的整个系统非常简单，通常来说，如果一个war包或者jar包里面包含一个应用的所有功能，则我们称这种架构为单体架构。
很多传统互联网公司或者创业型公司早期基本都会采用这样的架构，因为这样的架构足够简单，能够快速开发和上线。而且对于项目初期用户量不大的情况，这样的架构足以支撑业务的正常运行。

集群和垂直化

单体架构随着企业业务和用户量的增大，可能回面临以下挑战：

• 用户量越来越大，网站的访问量不断增大，导致后端服务器的负载越来越高。
• 用户量大了，产品需要满足不同用户的需求来留住用户，使得业务场景越来越多并且越来越复杂。
  当服务器的负载越来越高的时候，如果不进行处理，用户在网站上操作的响应会越来越慢。业务场景变多，意味着war包中的代码量会持续上升，并且各个业务代码之间的耦合度也会越来越高，后期代码的维护测试和上线也都相当痛苦。
  因此，可以从两个方面进行优化：
• 通过横向增加服务器，把单台机器变成多台机器的集群。
• 按照业务的垂直领域进行拆分，减少业务的耦合度，以及降低单个war包带来的伸缩性困难问题。
  对业务进行垂直拆分后，数据库也需要进行垂直分库，主要考虑到Tomcat服务器能够承受的流量大了之后，如果流量都传导到数据库上，会给数据库造成比较大的压力。

SOA

SOA（Service-Oriented Architecture），也就是面向服务的架构，从语义上来说，它和面向过程、面向对象、面向组件的思想是一样的，都是一种软件的组建以及开发的方式。核心目标是把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务，这些被提取出来的共享服务相对来说比较独立，并且可以重用。所以在SOA中，服务是最核心的抽象手段，业务被划分为一些粗粒度的业务服务和业务流程。
SOA主要解决的问题是：

• 信息孤岛
• 共享业务的重用

微服务架构

SOA将业务拆分为可共享复用的服务，可以在最大程度上避免共享业务的重复建设、资源连接瓶颈等问题。那么被拆分出来的服务是否也需要以业务功能为维度来进行拆分和独立部署，以降低业务的耦合以及提升容错性呢？
微服务就是这样的一种解决方法，我们可以把SOA看成微服务的超集，也就是多个微服务可以组成一个SOA服务。伴随着服务粒度的细化，会导致原本10个服务可能拆分为100个微服务，服务数量大就意味着服务的构建、发布、运维的复杂度也会成倍增加，所以实施微服务的前提是软件交付链路及基础设施的成熟化。
相比于SOA微服务关注的是：

• 微服务关注解耦，虽然解耦和可重用从特定角度来看是一样的，但本质上是有区别的，解耦是降低业务之间的耦合度，而重用性关注的是服务的服用。
• 微服务会更多地关注DevOps的持续交付上，因为服务粒度细化之后使得开发运维变得更加重要，因此微服务与容器化技术的结合更加紧密。

微服务的优点

• 复杂度可控
• 技术选型更加灵活
• 可扩展性强
• 独立部署
• 容错性好

微服务的挑战

• 故障排查变得复杂
• 服务监控变得困难
• 分布式架构本身的复杂性
• 服务依赖可能复杂
• 运维成本增高