微服务架构的理解以及和 RPC 的关系（理论篇）

什么是微服务架构？

微服务是一种架构概念，旨在通过将功能分解到各个离散的服务中已实现对解决的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是一个很有趣的概念，它的主要作用是将功能分解到离散的各个服务中，从而降低系统的耦合性，并提供更加灵活的服务支持。
概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
定义：围绕业务领域组件来创建应用，这些应用可以独立的进行开发，管理，和迭代。在分散的组件中使用云架构和平台式部署，管理和服务功能。使产品交付变得更加简单。
本质：用一些功能比较明确，业务比较精炼的服务区解决更大，更实际的问题

微服务架构的优点

有效的拆分应用，实现敏捷开发和部署
分工不同，以前我们可能是一人一个模块，现在可能是一人一个系统
架构不同，服务的拆分是一个技术含量很高的问题，拆分是否合理对以后发展影响巨大
部署方式不同，如果还像以前一样部署估计累死了，自动化运维不可不上
容灾不同，好的微服务可以隔离故障避免服务整体垮掉，坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应
扩展不同，微服务更容易按需求进行横向和纵向扩展

微服务做的事情是按照项目颗粒度进行服务的拆分，把模块单独拿出来做成每一个单独的小项目。微服务的主要特点有：
每一个功能模块是一个小项目，独立运行在不同进程或者机器上，不同功能可以由不同的人员开发独立开发，独立部署不需要依赖整体项目就可以启动单个服务，分布式管理，每个服务做好自己的事情就好，设计微服务时需要考虑数据库，是所有服务公用一个数据库还是一个服务一个数据库。

微服务的缺点

因为微服务架构的复杂度，对技术要求高，所以要考虑团队是否已经具备相关技术
公司业务是否适合进行微服务改造，并不是都一定适合，传统行业有很多复杂的垂直的业务架构。
微服务生态的技术又很多，并不是每一个技术方案都需要用上，适合自己的才是最好的

     对于微服务架构：技术上不是问题，意识比工具重要！

什么是RPC？

很多传统的phper并不懂什么是rpc，RPC全称Remote Procedure Call,中文译为远程过程调用，其实你可以把它理解为一种架构性上的设计，或者是一种解决方案。
通过RPC我们可以像调用本地方法一样调用别的机器上的方法，用户将无感服务器之间的通讯，RPC在微服务中起到了相当大的作用

本作品采用《CC 协议》，转载必须注明作者和本文链接