精读《从零开始做架构》( 五 ) _架构

无论采取何种分层维度，分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰，边界足够明显，让人看到架构图后就能看懂整个架构，这也是分层不能分太多层的原因。
分层架构另外一个典型的缺点就是性能，因为每一次业务请求都需要穿越所有的架构分层。
面向服务拆分：SOA、微服务SOA 的全称是 Service Oriented Architecture，中文翻译为“面向服务的架构” 。为了应对传统 IT 系统存在的问题，SOA 提出了 3 个关键概念。ESB:ESB 的全称是 Enterprise Service Bus 。松耦合:松耦合的目的是减少各个服务间的依赖和互相影响。服务：所有业务功能都是一项服务。
微服务架构（Microservice Architecture）是一种架构概念，微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。
SOA 和微服务本质上是两种不同的架构设计理念，只是在“服务”这个点上有交集而已。

文章插图

文章插图

微服务具体有哪些坑：

服务划分过细，服务间关系复杂
服务数量太多，团队效率急剧下降
调用链太长，性能下降
调用链太长，问题定位困难
没有自动化支撑，无法快速交付
没有服务治理，微服务数量多了后管理混乱

微服务架构最佳实践：
服务粒度：“三个火枪手”原则，即一个微服务三个人负责开发。“三个火枪手”的原则主要应用于微服务设计和开发阶段，如果微服务经过一段时间发展后已经比较稳定，处于维护期了，无须太多的开发，那么平均 1 个人维护 1 个微服务甚至几个微服务都可以。当然考虑到人员备份问题，每个微服务最好都安排 2 个人维护，每个人都可以维护多个微服务。
拆分方法：基于业务逻辑拆分，基于可靠性拆分，基于性能拆分，基于可扩展拆分（将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务）
面向功能拆分：微内核架构微内核架构（Microkernel architecture）模式也被称为插件架构（plugin architecture）模式。可以用来实现基于产品的应用, 比如Eclipse，在微内核的基础上添加一些插件，就可以提供不同的产品，如C++, JAVA等。
微内核包含两个组件： core system 和 plug-in modules 。应用逻辑被分隔成核心系统和插件模块，可以提供可扩展的，灵活的，特性隔离的功能。

文章插图

微内核的架构本质就是将变化部分封装在插件里面，从而达到快速灵活扩展的目的，而又不影响整体系统的稳定。
微内核的核心系统设计的关键技术有：插件管理（有哪些插件，怎么加载，什么时候加载）、插件连接（插件怎么连接到核心系统）和插件通信（插件之间的通信）。相关框架技术：OSGi 的全称是 Open Services Gateway initiative 。
软件可扩展性方法总结：