软件架构模式 mark Richards - 读后总结 4 - 微服务架构
微服务架构模式作为替代单体应⽤用和⾯面向服务架构的⼀一个可⾏行的选择，在业内迅速取得进展。由于这个架构 模式仍然在不断的发展中，在业界存在很多困惑——这种模式是关于什么的？它是如何实现的？本报告的这 部分将为你提供关键概念和必要的基础知识来理解这⼀一重要架构模式的好处(和取舍)，以此来判断这种架构 是否适合你的应⽤用。
不管你选择哪种拓扑或实现风格,
有几种常见的核心概念适用于一般架构模式。第一个概念是 单独部署单元 。
微服务架构的每个组件都作为一个独立单元进行部署，让每个单元可以通过有效、简化的传输 管道进行通信，同时它还有很强的扩展性，
应用和组件之间高度解耦，使得部署更为简单。 也许要理解这种模式，
最重要的概念就是服务组件（service component）。不要考虑微服务架构内部的服务，而最好是考虑服务组件，从粒度上讲它可以小到单一的模块，或者大至一个应⽤用程序。
服务组件包含一个或多个模块（如Java类），
这些模块可以提供一个单一功能（如，为特定的城市或城镇提供天气情况），
或也可以作为一个大型商业应用的一个独立部分（如，股票交易布局或测定汽⻋车保险的费率）。
在微服务架 构中，正确设计服务组件的粒度是一个很大的挑战。在接下来的服务组件部分对这一挑战进行了详细的讨论
模式拓扑
但三个主要的拓扑结构脱颖而出，
最常见和流行的有:基于REST API 的拓扑结构,基于REST的应⽤用拓扑结构和集中式消息拓扑结构。 基于REST的API拓扑适用于网站，通过某些API对外提供小型的、⾃自包含的服务。这种拓扑结构,如图4 - 2所示,
由粒度非常细的服务组件（因此得名微服务）组成，
这些服务组件包含一个或两个模块并独立于其他服务来执行特定业务功能。在这种拓结构扑中,这些细粒度的服务组件通常被REST-based的接口访问，而这个接口是通过一个单独部署的web API层实现的。
此种拓扑的例⼦子包含一些常见的专用的、基于云的RESTful web service，大型网站像Yahoo, Google, and Amazon都在使用。
集中式消息拓扑
微服务架构模式中另一个常见的方法是 集中式消息拓扑。
该拓扑与前面提到的基于REST的应用拓扑类似，不同的是，application REST- based拓扑结构使用REST进行远程访问，
而该拓扑结构则使用一个轻量级的集中式消息代理（如，ActiveMQ, HornetQ等等）。不要将该拓扑与⾯面向服务架构模式混淆 或将其当做SOA简化版（“SOA-Lite”），
这点是极其重要的。该拓扑中的轻量级消息代理（Lightweight Message Broker）不执行任何编排,转换,或复杂的路由;相反,它只是一个轻量级访问远程服务组件的传输工具。
集中式消息拓扑结构通常应用在较大的业务应用程序中，或对于某些对传输层到⽤用户接⼝层或者到服务组件 层有较复杂的控制逻辑的应用程序中。该拓扑较之先前讨论的简单基于REST的拓扑结构，
其好处是有先进的排队机制、异步消息传递、监控、错误处理和更好的负载均衡和可扩展性。
与集中式代理相关的单点故障 和架构瓶颈问题已通过代理集群和代理联盟（将⼀一个代理实例为分多个代理实例，把基于系统功能区域的吞 吐量负载划分开处理）解决。
避免依赖和编排
微服务架构模式的主要挑战之⼀一就是决定服务组件的粒度级别。如果服务组件粒度过粗，那你可能不会意识 到这个架构模式带来的好处（部署、可扩展性、可测试性和松耦合），然⽽而,服务组件粒度过细将导致服务编 制要求,这会很快导致将微服务架构模式变成⼀一个复杂、容易混淆、代价昂贵并易于出错的重量级⾯面向服务架 构。 如果你发现需要从应⽤用内部的⽤用户接⼝口或API层编排服务组件，那么很有可能你服务组件的粒度太细了。如果 你发现你需要在服务组件之间执⾏行服务间通信来处理单个请求,那么很有可能要么是你服务组件的粒度太细 了，要么是没有从业务功能⾓角度正确划分服务组件。
服务间通信，可能导致组件之间产⽣生耦合，但可以通过共享数据库进⾏行处理。例如，若⼀一个服务组件处理⺴⽹网 络订单⽽而需要⽤用户信息时，它可以去数据库检索必要的数据，⽽而不是调⽤用客户服务组件的功能。
共享数据库可以处理信息需求，但是共享功能呢？如果⼀一个服务组件需要的功能包含在另⼀一个服务组件内， 或是⼀一个公共的功能,那么有时你可以将服务组件的共享功能复制⼀一份（因此违反了DRY规则：don’t repeat yourself）。为了保持服务组件独⽴立和部署分离，微服务架构模式实现中会存在⼀一⼩小部分由重复的业务逻辑⽽而 造成的冗余，这在⼤大多数业务应⽤用程序中是⼀一个相当常⻅见的问题。⼩小⼯工具类可能属于这⼀一类重复的代码。 如果你发现就算不考虑服务组件粒度的级别，你仍不能避免服务组件编排,这是⼀一个好迹象,可能此架构模式不 适⽤用于你的应⽤用。由于这种模式的分布式特性，很难维护服务组件之间的单⼀一⼯工作事务单元。这种做法需要 某种事务补偿框架回滚事务,这对此相对简单⽽而优雅的架构模式来说，显著增加了复杂性。