目录
一、服务架构演进史
架构不是被凭空发明出来的,而是一个持续演进的结果
1.1原始分布式时代
Open Software Foudation 邀请 业界主流计算机厂商一起参与,制定了 Distributed Computing Environment;这是一套相对完整的分布式服务组件规范与参考实现,包括DEC/RPC、DCE/DFS、服务认证规范、时间服务、命名与目录服务、UUID等
调用本地方法 和 调用远程方法之间的复杂度不可同日而语;RPC不可能再使用以内联为代表的传统编译优化来提升速度,“远程”意味着网络环境下的新问题,比如服务发现、负载均衡、熔断、隔离、降级、序列化协议、传输协议、认证、授权、网络安全、分布式数据一致性;因此,性能上,RPC和LPC的性能差距势必有鸿沟;分布式相较于单机本地调用,必然导致性能上的妥协,所以DEC未能在生产环境被实际应用。
也就是说,一个功能在本地运行的时间足够长,长到分布式的调用开销与之相比完全可以忽略,才考虑进行分布式;换句话说,某个功能能够进行分布式,并不意味着,它就应该进行分布式。
1.2单体系统时代
单体系统 aka 巨石系统,本质上,是一个进程上面运行着系统所有的代码,单体不意味着一定糟糕,糟糕的是大型的单体系统;对于小型系统,单台机器足够支撑其运行,开发、测试、部署都更简单,且系统中各模块间调用方式都是进程内调用,不会发生IPC,所以运行的效率也是极高的。
单体的不足,必须在软件的性能需求超过单机、RD规模超过2 Pizza Team的前提下,才有讨论价值。
另外,单体系统本身不太可能是“铁板一块”,纵向看,软件一般都是分层设计的,横向看,一般也能按照技术、功能、职责等维度,将软件拆分为多模块,或者从横向拓展来看,在负载均衡后部署若干相同单体系统副本,来分摊流量压力,也是常见的手段;因此,单体系统难点不在于拆分,而在于拆分后的自治与隔离能力。构建可靠系统的观念从追求尽量不出错,到正视出错是必然,才是微服务架构得以挑战并逐步取代单体架构的根本原因
单体系统的利弊:
优点:
无需考虑网络分区、对象复制带来的性能损失,进程内调用简单高效
缺点
任一部分代码缺陷会带来全局影响,而不仅是影响某一个功能、模块;
无法做到单独对一部分代码进行停止、更新、升级;也即是可维护性差,持续升级、更新时往往要指定专门的停机更新计划,灰度发布、A/B测试也更难;大规模的单体应用,在修改后的部署成本、技术升级后的迁移成本会变得很昂贵;另外单体常常意味着技术同构,单体的技术异构方案很难做到优雅