架构 单体与微服务
架构 单体与微服务
1.1 单体应用
单体应用由很多个组件组成，这些组件紧密 精合在 起，由于它们在同操作系统进程中运行，所以在开发 部署、管理的时候必须 以同 个实体进行单体应用来说， 即使是某 件中 个小的修改，都需要重新部署整个应用 组件缺乏严格的边界定义，相互依赖，日积月累导致系统杂度提升，整体质量也急剧恶化。
运行 个单体应用，通常需要 台能为整个应用提供足够资源的高性能服务器为了应对不断增长的系统负荷，需要通过增加 CPU、内存或其他系统资源的方式来对服务器做垂直扩展，或者增加更多的跑这些应用程序的服务器的做水平扩展垂直扩展不需要应用程序做任何变化，但是成本很快会越来越高，井且通常会有瓶颈，如果是水平扩展，就可能需要应用程序代码做比较大的改动，有时候甚至是不可行的，比如系统的 些组件非常难于甚至不太可能去做水平扩展（像关系型数据库〉 如果单体应用的任何 个部分不能扩展，整个应用就不能扩展，除非我们想办法把它拆分开。
1.2
1.2.1 微服务
这些 问题迫使我们将复杂的大型单体应用，拆分为小的可独立部署的微服务组件，每个微服务 以独立的进程运行，，并通过简单且定义良好的接口（ API)与其他的微服务通信。
因为每个微服务都是独立的进程，提供相对静态的 API ，所以独立开发和部署
单个微服务成了可能 只要 API 不变或者向前兼容，改动 个微服务，并不会要求
对其他微服务进行改动或者重新部署。
1.2.2 微服务扩容
面向单体系统，扩容针对的是整个系统，而面向微服务架构，扩容却只需要针对单个服务，这意味着你可以选择仅扩容那些需要更多资源的服务而保持其他的服务仍然维持在原来的规模。如图 1.2 所示，三种组件都被复制了多个，并以多进程的方式部署在不同的服务器上，而另外的组件只能以单体进程应用运行。当单体应用因为其中 一部分无法扩容而整体被限制扩容时，可以把应用拆分成多个微服务，将那些能进行扩容的组件进行水平扩展，不能进行扩容的组件进行垂直扩展。
1.2.3 k8s 微服务的缺点
1.2.3.1 解耦带来的缺点
像大多数情况一样，微服务也有缺点。若你的系统仅包含少许可部署的组件，管理那些组件是简单的。决定每个组件部署在哪儿是不重要的，因为没有那么多选择。当组件数量增加时，部署相关的决定就变得越来越困难。因为不仅组件部署的组合数在增加，而且组件问依赖的组合数也在以更大的因素增加。整体复杂性变大。
1.2.3.2 代码调复杂度变大
因为跨了多个进程和机器，使得调试代码和定位异常调用变得困难。
1.2.3.3 环境需求的差异
正如己经提到的， 个微服务架构中的组件不仅被独立部署，也被独立开发。因为它们的独立性，出现不同 的团队开发不同的组件是很正常的事实 每个团队都有可能使用不同的库并在需求升级时替换它们 如图 1.3 所示，因为组件之间依赖的差异性，应用程序需要同 个库的不同版本是不可避免的。
