阅读的目的微服务是一种漫衍式系统解决方案，最近几年事情中使用的是微服务架构来部署服务，但自己接触到的主要是业务开发相关的事情，对微服务的相识主要偏实战方面，而对于构建、集成、剖析、测试、部署、监控、架构演进等相关内容没有系统性的相识过，此书内容比力全面，包罗了微服务设计的种种主题，读这本书主要希望可以系统性的相识一下微服务的方方面面。本书的整体框架这本书主要基于主题来组织内容，主要包罗以下主题：微服务基本观点的先容，如何构建微服务，什么样的服务集成技术对微服务最有资助，如何把一个大的单块系统剖析成微服务，如何部署微服务，如何测试微服务以确保软件质量，对于庞大的漫衍式系统如何监控，如何宁静的使用微服务，使用康威定律解释开发人员组织结构和系统设计的相互租用，先容规模化后微服务面临的问题以及切合应对问题。

这篇文章只是选取书中部门看法拿来讨论，不是总结和归纳综合。本书的目录微服务界说对于微服务，作者界说为一些协同事情的小而自治的服务，“小而自治”可以使用单一职责原则来解释：把因相同原因而变化的工具聚合在一起，而把因差别原因而变化的工具分散开。这个原则也可以用来指导单个服务的微服务拆分。

多小算小：澳大利亚RealEstate.com.au的Jon Eaves认为，一个微服务应该可以在两周内完全重写。服务是否够小，作者认为需要思量以下因素：服务越小，微服务架构的优点和缺点也就越显着微服务越小，独立性带来的利益就越多，但也就越庞大如果开发者不再以为代码库过大，那就可以认为足够小了。

自治：一个微服务是一个独立的实体，独立部署，服务之间通过网络挪用举行通信，从而增强服务之间的隔离性，制止耦合。微服务的优点：技术异构性：因为单个微服务力度足够小，在由多个微服务组成的系统中，可以在差别的微服务中使用差别的技术，好比使用差别的语言、框架、差别的数据库等。弹性：微服务可以部署在多个机械上来降低功效完全不行用的概率，这样当一个服务不行用时也可以制止级联故障的发生。

扩展：可以对特定的模块举行扩展或缩容，好比性能要求高的部署在性能好的机械上，性能要求低的部署在性能稍差的机械上简化部署：部署时只需要部署修改的部门而不是把整个大的服务。与组织架构相匹配：差别模块由差别的人员维护开发可替代性：对于大的服务，重构替代比力难，可是微服务就相对简朴，可能只需要几天就能完成。

微服务虽然利益许多，可是微服务并不是没有缺点，更不是银弹，使用微服务之前需要思量清除。架构师架构师的一个重要职责是确保团队有配合的技术愿景，以资助我们向客户交付他们想要的系统。

作者有一个看法特别有意思，他认为架构师是参考其它行业好比修建师来命名的，可是“架构师”并不需要像“修建师”那样需要对设计保证足够的准确，且对产物负有不行推卸的责任，可是软件“架构师”却需要保证软件有足够的灵活性和适应性，而且能够凭据用户的需求举行演化。这么看来，软件设计师更像是都会计划师，只需要保证大偏向上的正确，对于模块内的详细设计可以随机应变。指导原则软件设计的关键是取舍，而哪些取哪些舍就需要满足一些原则，而原则自己也需要取舍，最好不要凌驾10条，否则当原则太多可能会发生冲突也未便影象，可以参考​【1】 https://www.12factor.net/zh_cn/ 的12项原则:I. 基准代码一份基准代码，多份部署II. 依赖显式声明依赖关系III. 设置在情况中存储设置IV. 后端服务把后端服务看成附加资源V. 构建，公布，运行严格分散构建和运行VI. 历程以一个或多个无状态历程运行应用VII. 端口绑定通过端口绑定提供服务VIII. 并发通过历程模型举行扩展IX. 易处置惩罚快速启动和优雅终止可最大化结实性X. 开发情况与线上情况等价尽可能的保持开发，预公布，线上情况相同XI. 日志把日志看成事件流XII. 治理历程后台治理任务看成一次性历程运行列原则简朴，但要和实践相联合才好。

什么样的服务是好服务作者给出的两个观点是：1、松耦合；2、高内聚。这两个观点也不仅仅是微服务的设计理念，而是所有系统设计的基本要求。做到松耦合，在修改一个服务的时候就不需要修改另一个服务，这样就能够做到独立部署一个服务而不需要修改系统的其它部门。

做到高内聚，也就能在需要修改一个功效时只需要修改一个服务就能实现需求。可见，松耦合和高内聚本质上可以到达相同的目的。不要过早划分服务在服务有明确的界限之前，最好不要划分服务。究竟拆分服务比把服务合并起来更容易一些。

当一个服务业务界限逐渐明确时，再凭据业务界限逐步拆分服务。对于单个大服务的剖析，也建议从剖析数据库开始，将杂乱的依赖理清。服务的集成多个服务的集成有多种方式，好比共享数据库、REST挪用、远程历程挪用。

同时服务间挪用也有同步伐用和异步伐用两种方式。这两种方式各有各的利益，差别场景可能需要选择差别的挪用方式。如果使用同步服务，提倡一个挪用后挪用方会阻塞自己并等候整个操作的完成；如果使用异步通信，挪用方不需要等候操作完成后就可以返回，甚至可能不需要体贴这个操作是否完成。接纳异步的方式就需要保证异步伐用的可靠性（好比失败了怎么处置惩罚，异步任务需要保证幂等）。

服务部署服务拆分后，服务的数量可能会是原来的几倍、几十倍，可能一个需求的改动会设计几个或者更多的服务部署，这时服务的部署就会酿成一个无法制止的问题。一个比力好的做法是将连续集成映射到服务，在代码修改后通过设置自动部署。这里有一个需要注意的点就是可能需要对差别的服务定制化差别的镜像，d。

本文来源：开云app官网-www.kegongyanmian.com