Open johnnian opened 7 years ago
作者:TW洞见
感觉这本书上的几篇文章挺好的，对于微服务的特性、实施都有一定的描述。
目前手头刚好有一个项目，正在做架构上的优化与演进，虽然不完全用到微服务，但是也借用了一些框架与工具（Spring Cloud）。生产上的部署，目前还不敢直接用 Docker容器，不过自己在本地演练上线的时候，就用了 Docker容器模拟生产环境。
这本书更像是几篇文章的集合，读薄了，就下面的几点：
@ James Lewis and Martin Fowler
微服务是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合， 为用户提供最终价值。 每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通 (通常是基于HTTP协议的RESTful API)。 每个服务都围绕着具体业务进行构建，并且能够被独立地部 署到生产环境、类生产环境等。 另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服 务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
微服务架构通过将功能分解到多个独立的服务，以实现对解决方案或者复杂系统的解耦。
微服务的实施，并不是凑热闹，而是由于实际的需求导致的；
最终应当是需求、是人来决定 架构而非架构决定需求。
下面几点可以判断当前的系统是不是用到微服务：
微服务架构的好处：
相对于单体架构和SOA，它的主要特点是组件化、松耦合、自治、去中心化. 1.一组小的服务 服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事 情。 2.独立部署运行和扩展 每个服务能够独立被部署并运行在一个进程内。 3.独立团队和自治 团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不 需要统一的指挥中心。
实施微服务不是目的，而是应用在当前的业务场景下，单体无法灵活调度了，此时自然会想要对当前的架构进行解耦。
所以，在一个崭新的项目中，可以先使用单体结构（可以快速响应，部署、测试的时候也可以整体覆盖），随着业务、功能、并发的增多，使用演进式的架构，逐步肢解单体，使得架构越来越灵活。
这个就需要注意：使用单体结构，开发的时候最好可以对内部的代码层次划分好，这样也便于后面的拆分。例如，Web的话，划分： controller、service、dao、task；对于业务来说，根据接入端的不同也可以划分下；如果单体没有划分好，后面拆的时候非常困难。
引用书中的内容：
为了追求生产力的最大化，一开始我们可以选择从一个单体架构开始，然后争取在微服务架构生产力超 越单体架构的那个复杂度点时切换到微服务架构上来，这样才能实现生产力的最大化。 这就是Martin Fowler提出的单体应用优先原则(MonolithFirst)，以单体架构开始，通过演进式设计逐渐重构到微服 务架构。
在马丁即将发表的一篇文章里提到，我们并不建议在一个崭新的项目中一开始就使用微服务进行开发。因为你很可能并不真的理解业务领域，也很难理解各个服务的边界。 因此在这种项目中，可以先做成单块的，进行适当的模块化，加深理解之后再考虑演进成微服务。
跟前面讲的一样，我们始终建议在完全透彻的理解业务背景的前提下再尝试使用微服务。 在一个崭新的项目上，始终建议从一个单块架构开始，因为你不可避免地会犯一些边界划分的错误，除非你真的是对于这个领域烂熟于胸。
就如庖丁解牛一样，拆分需要摸清内部的构造脉络，在筋骨缝隙处下刀。 (单体应用)拆分的关键在于正确理解业务，识别单体内部的业务领域及其边界，并按边界进行拆分。 系统可由单体结构开始，不断的演进。
这段时间在生产环境部署我们的项目（使用负载均衡、带有一些微服务），发现部署是在是复杂，花费两个人，用一天的时间才部署好。
架构越灵活，意味着运维需要做的事情也就更多，像基础设置环境的搭建，业务系统的配置等工作比较繁琐。
微服务架构虽然看起来非常美好，但是也有很大的附加成本.
微服务相比于传统架构，增加了大量的运维负担。有更多的东西需要部署，有更多的地方需要监控，出错的地方自然也成倍增加，有更多的数据库，对应的需要更多的备份。
我们发现另外一种必要的监控是分布式的日志收集。这允许我们从不同的服务器收集日志并且可以做联 合查询。 这样分布式的日志允许我们跟踪一个请求在系统不同服务中的跳转过程。
缺乏有效的监控和日志管理，产品环境定位困难。
通过自动化脚本将应用部署到生产环境。 采用部署流水线，由自动化脚本实现全环境的快速部署，包括配置管理、版本管理等。
这一点书中没讲, 但是微服务之间的调用，很多使用RESTFul API，对于接口文档的规范化 也是需要注意的。
需要考虑下使用第三方工具，自动生成接口文档；
学习了
hunt-up
commented
3 years ago hunt-up
commented
3 years ago
作者:TW洞见
感觉这本书上的几篇文章挺好的，对于微服务的特性、实施都有一定的描述。
目前手头刚好有一个项目，正在做架构上的优化与演进，虽然不完全用到微服务，但是也借用了一些框架与工具（Spring Cloud）。生产上的部署，目前还不敢直接用 Docker容器，不过自己在本地演练上线的时候，就用了 Docker容器模拟生产环境。
这本书更像是几篇文章的集合，读薄了，就下面的几点：
一、微服务的定义
@ James Lewis and Martin Fowler
微服务的实施，并不是凑热闹，而是由于实际的需求导致的；
二、微服务的特点&好处
下面几点可以判断当前的系统是不是用到微服务：
微服务架构的好处：
三、微服务演进式的实践
1.架构演进的思路
实施微服务不是目的，而是应用在当前的业务场景下，单体无法灵活调度了，此时自然会想要对当前的架构进行解耦。
所以，在一个崭新的项目中，可以先使用单体结构（可以快速响应，部署、测试的时候也可以整体覆盖），随着业务、功能、并发的增多，使用演进式的架构，逐步肢解单体，使得架构越来越灵活。
这个就需要注意：使用单体结构，开发的时候最好可以对内部的代码层次划分好，这样也便于后面的拆分。例如，Web的话，划分： controller、service、dao、task；对于业务来说，根据接入端的不同也可以划分下；如果单体没有划分好，后面拆的时候非常困难。
引用书中的内容：
2.挑战
这段时间在生产环境部署我们的项目（使用负载均衡、带有一些微服务），发现部署是在是复杂，花费两个人，用一天的时间才部署好。
架构越灵活，意味着运维需要做的事情也就更多，像基础设置环境的搭建，业务系统的配置等工作比较繁琐。
引用书中的内容：
3.实施微服务后，需要同步考虑的内容：
这一点书中没讲, 但是微服务之间的调用，很多使用RESTFul API，对于接口文档的规范化 也是需要注意的。
需要考虑下使用第三方工具，自动生成接口文档；