组件，是一个可以独立更换和升级的单元。 就像 PC 中的 CPU、内存、 显卡、 硬盘一 样，独立且可以更换升级而不影响其他单元。 在微服务架构中，需要我们对服务进行组件化分解。 服务，是一种进程外的组件，它 通过 HTTP 等通信协议进行协作，而不是像传统组件那样以嵌入的方式协同工作。 每一个 服务都独立开发、 部署，可以有效避免一个服务的修改引起整个系统的重新部署。 打一个不恰当的比喻，如果我们的 PC 组件以服务的方式构建，那么只维护主板和一 些必要外设之后，计算能力通过一组外部服务实现，我们只需要告诉 PC 从哪个地址来获 得计算能力，通过服务定义的计算接口来实现我们使用过程中的计算需求，从而实现 CPU 组件的服务化。 这样原本复杂的 PC 服务得到了轻量化的实现，我们甚至只需要更换服务 地址就能升级PC 的计算能力。
按业务组织团队
当决定如何划分微服务时，通常也意味着我们要开始对团队进行重新规划与组织。 按 以往的方式，我们往往会从技术的层面将团队划分为多个，比如DBA团队、运维团队、后 端团队、 前端团队、 设计师团队等。 若我们继续按这种方式组织团队来实施微服务架构开 发，当有一个服务出现问题需要更改时，可能是一个非常简单的变动，比如对人物描述增 加一个字段，这需要从数据存储开始考虑一直到设计和前端， 虽然大家的修改都非常小， 但这会引起跨团队的时间耗费和预算审批。
在实施微服务架构时，需要采用不同的团队分割方法。 由于每一个微服务都是针对特 定业务的宽栈或是全栈实现，既要负责数据的持久化存储， 又要负责用户的接口定义等各 种跨专业领域的职能。 因此，面对大型项目的时候，对于微服务团队的拆分更加建议按业 务线的方式进行拆分， 一方面可以有效减少服务内部修改所产生的内耗； 另一方面，团队 边界可以变得更为清晰。
做 “产品” 的态度
在实施微服务架构的团队中，每个小团队都应该以做产品的方式，对其产品的整个生 命周期负责。 而不是以项目的模式，以完成开发与交付并将成果交接给维护者为最终目标。
开发团队通过了解服务在具体生产环境中的情况， 可以增加他们对具体业务的理解， 比如， 很多时候， 一些业务中发生的特殊或异常情况， 很可能产品经理都并不知晓， 但细 心的开发者很容易通过生产环境发现这些特殊的潜在问题或需求。 所以， 我们需要用做 “产品” 的态度来对待每一个微服务， 持续关注服务的运作情况， 并不断分析以帮助用户来改善业务功能。
智能端点与哑管道
在单体应用中， 组件间直接通过函数调用的方式进行交互协作。 而在微服务架构中， 由于服务不在一个进程中， 组件间的通信模式发生了改变， 若仅仅将原本在进程内的方法 调用改成RPC方式的调用， 会导致微服务之间产生烦琐的通信， 使得系统表现更为糟糕， 所以， 我们需要更粗粒度的通信协议。 在微服务架构中， 通常会使用以下两种服务调用方式：
• 第一种， 使用 HTTP的 RESTful API或轻量级的消息发送协议， 实现信息传递与服 务调用的触发。
• 第二种， 通过在轻量级消息总线上传递消息， 类似 RabbitMQ 等一些提供可靠异步 交换的中间件。
在极度强调性能的情况下， 有些团队会使用二进制的消息发送协议， 例如 protobuf。 即使是这样， 这些系统仍然会呈现出 “智能瑞点和哑管道” 的特点， 这 是为了在易读性与高效性之间取得平衡。当然大多数Web 应用或企业系统并不需 要在这两者间做出选择， 能够荻得易读性已经是一个极大的胜利了。
一Martin Fowler
去中心化治理 (有点像区块链的概念)