阿里技术大牛：一份架构师成神路线图( 八 ) _架构师

⑧业务拆分

文章插图

特征：系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。
描述：为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统，纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。
横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。
⑨分布式服务

文章插图

文章插图

特征：公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。
描述：随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。
⑩分布式服务的问题和挑战：

当服务越来越多时，服务 URL 配置管理变得非常困难， F5 硬件负载均衡器的单点压力也越来越大。
当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑?什么时候该加机器?
服务多了，沟通成本也开始上升，调某个服务失败该找谁?服务的参数都有什么约定?
一个服务有多个业务消费者，如何确保服务质量?
随着服务的不停升级，总有些意想不到的事发生，比如 Cache 写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面?服务是否可以功能降级?或者资源劣化?

针对这些问题，下述的单元化架构，微服务架构以及 Serveless 架构可以一定程度解决，另外针对业务系统，需要做到业务与业务隔离、管理域和运行域分开、业务与平台隔离方可解决上述问题。
单元化架构
①什么是单元化：单元化架构是从并行计算领域发展而来。在分布式服务设计领域，一个单元(Cell)就是满足某个分区所有业务操作的自包含的安装。
而一个分区(Shard) ，则是整体数据集的一个子集，如果你用尾号来划分用户，那同样尾号的那部分用户就可以认为是一个分区。单元化就是将一个服务设计改造让其符合单元特征的过程。
②单元化的必要性：随着硬件的不断升级，计算机硬件能力已经越来越强， CPU 越来越快，内存越来越大，网络越来越宽。这让我们看到了在单台机器上垂直扩展的机会。
尤其是当你遇到一个性能要求和容量增长可以预期的业务，单元化给我们提供另外的机会，让我们可以有效降低资源的使用，提供更高性能的服务。
更高性能更低成本是我们的主要目标，经过单元化改造，我们得以用更少(约二分之一)的机器，获得了比原来更高(接近百倍)的性能。
性能的提升很大部分原因在于服务的本地化，而服务的集成部署又进一步降低了资源的使用。
除了性能收益，还有很多收益，比如更好的隔离性，包括请求隔离和资源隔离，比如更友好的升级，产品可以灰度发布等。单元化改造后对高峰的应对以及扩容方式等问题的解决。