1.微服务架构全景图：

(1) 日志系统（日志中心）：主要用于收集和管理微服务应用产生的日志，快速帮助开发人员定位异常，同时还可以在日志系统中搜索历史日志，日志配合告警系统，可以按照日志信息的等级（error、info等等），日志的某一个具体字段设置告警规则，通过短信、企业微信、邮箱提醒开发人员，帮助开发人员及时发现并解决问题。

(2) 监控中心：主要用于实时监控微服务运行情况，如CPU、内存、OPS、成功率等。设置各项指标的阙值，当服务应用程序的某个指标达到设置的阙值时，发出警告并提醒开发人员及时处理问题。

(3) 配置中心：主要用于统一管理微服务的配置，开发人员或者运维人员通过配置中心可以实时动态更新微服务的配置参数，不需要重启系统，配置参数即可生效。

(4) 部署中心：主要用于编译并打包微服务源码并将其部署到Docker容器中，技术可以选择Jenkins(慢慢淘汰)和GitHubCI(主流)。

(5) 注册中心：主要用于管理微服务相关的配置信息，如服务提供者信息，常用技术ZooKeeper等等。

(6) 消息中心：主要用于微服务之间的相互解耦，常用的技术有Kafka、RabbitMQ等，大型互联网企业都有自己的信息中心，可以在消息中心管理topic、查看消息队列的消费情况、查看消息队列的消费速度和堆积情况等等，如果队列出现消息堆积，那么还会结合监控中心进行告警通知。

(7) 追踪中心：主要用于管理微服务的调用轨迹。

(8) 容器化：容器化技术促进微服务架构落地，目前流行的技术主要是Docker技术。

(9) 应用层：在应用层中主要相关的业务服务有用户服务、订单服务、产品服务等等，各个微服务由不同的开发团队管理，每个团队可以选择适合自己业务开发的语言和技术框架，开发语言如java、go、php，技术架构如目前流行的微服务脚手架SpringBoot。

2.微服务架构各部分协调与分工：

微服务架构各部分之间的协调与分工

(1) 开发人员将代码提交到代码仓库（GitHub）。

(2) 部署中心从配置中心获取服务相关的配置参数。

(3) 部署中心将应用程序和配置文件一同复制到DOcker镜像中，并上传镜像到镜像仓库。

(4) 服务发布时，从镜像仓库下载指定的镜像，启动并运行容器，容器启动后，会自动将配置信息写入注册中心。

(5) 用户通过浏览器或者移动访问应用系统时，首先请求进入网关。

(6) 网关通过服务名称从服务注册中心获取服务所在的IP地址和端口，根据服务地址（IP地址和端口）以反向代理的方式，结合一定的负载均衡策略调用具体的容器。

(7) 服务在容器中运行过程中会产生大量的日志，这些日志会被收集到日志系统中进行管理，监控中心可以监控容器的运行情况，并通过可视化的报表展示数据，追踪中心提供图形化界面查看服务之间的调用轨迹以及所产生的调用时延迟等。

3.微服务类型：

(1) 基础服务：基础组件，与具体的业务无关，比如短信服务、邮件服务等等，这种服务最容易拆出来做微服务，是第一优先级分离出来的服务。

(2) 业务服务：一些垂直的业务系统，只处理单一的业务类型，比如评论服务、点赞服务、Feed服务等等，这类职责比较单一，根据业务情况来选择是否迁移，是第二优先级分离出来的服务。

(3) 前置服务：前置服务一般为服务的接入或者输出服务，比如网站的前端服务、App的服务接口等等，这是第三优先级分离出来的服务。

(4) 组合服务：组合服务涉及具体业务，比如订单服务，需要调用很多垂直的业务服务，这类服务一般放到最后进行微服务化架构改造，因为这类服务最为复杂，除非涉及大的业务逻辑变更，否则不会轻易进行迁移。

4.微服务拆分原则与步骤：

(1) 梳理业务：梳理出业务模块以及模块之间的依赖关系。这个过程需要和相关人员一起评估。

(2) 优先对公共业务进行优化，如用户服务、邮箱服务、消息服务等等。

(3) 对业务服务进行服务化，切分的服务之间尽量不要有任何的关联，开始服务化时，先粗粒度地进行服务划分，之后在慢慢地根据业务的情况进行细粒度服务地切分，不必追求一步到位，微服务拆分后，服务之间的依赖关系复杂，如果循环调用，升级的适合就很麻烦，不知到应该先升级哪个，后升级哪个，难以维护。

(4) 微服务的领域模型设计，微服务拆分完成后，需要设计每个服务设计的数据库表、表与表之间的关系，数据库表设计需要文档化，方便相关开发人员查阅。

(5) 定义微服务接口，数据库表设计完成后，需要定义服务接口，让外部调用，服务接口的入参、出参、方法的名称以及注释等都需要仔细思考，必要时还需要开会评审，服务接口也需要文档化，方便调用者查阅。