1. 模块和组件

从设计上来看，组件强调复用，模块强调职责(内聚、分离)，或者说组件是达到可复用要求的模块。

模块，偏向设计的概念(inside)：

1、用于在项目中划分相对独立的功能，模块是独立功能分装起来的代码块。

2、模块更偏重逻辑上区分

模块更偏重逻辑上区分，封装上可以和其他模块混合。

3.模块化一种把系统分离成独立功能模块的方法.( 系统功能 )

组件，偏向发行的概念(outside)：

1、强调的是“跨项目的可重用性”这层意思。

比如“XXX采集卡通用远程监控组件”，表示这个东东是完成远程监控功能，并且是为了可重用而开发的. 这个组件本身由采集卡驱动、网路传输、信号处理等诸多模块共同实现。

2、作为需要被第三方客户使用的独立工具，组件一般都有独立的封装。比如一个组件用符合COM接口规范的DLL发行，某些时候发行库大到包含一系列可执行文件、系统服务。

2. 微服务

微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。

服务化就是把传统的单机应用中通过本地方法调用，改造成通过 RPC 接口产生的远程方法调用。

1. 服务拆分粒度更细。微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。

2. 服务独立部署。每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署多个 Docker 实例，每个 Docker 实例可以部署一个微服务的代码。

3. 服务独立维护。每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。

4. 服务治理能力要求高。因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。