微服务 是什么？
在传统的软件开发中，整个应用程序代码被组织在一个单一的代码库中，并且通常会有以下的拆分代码形式：
- 根据特征进行拆分：如mvc模式
- 根据功能进行拆分：在较大的项目中，代码可能被封装在一个处理不同业务的包中，而且包可能在内部被拆分
无论如何拆分，两者的代码最终将在一个库中开发和管理。参考：谷歌的单一代码库管理
微服务是上述二次拆分方法的延伸。将代码按函数划分为多个包。每个包是一个可以独立运行的单代码库。
区别如下：
微服务有哪些优势？
降低复杂性
将整个应用的代码按功能对应拆分为小且独立的微服务代码库，这不禁让人联想到 Unix 哲学：Do One Thing and Do It Well，在传统单一代码库的应用中，模块之间是紧耦合且边界模糊的，随着产品不断迭代，代码的开发和维护将变得更为复杂，潜在的 bug 和漏洞也会越来越多。
提高扩展性
在项目开发中，可能有一些代码经常在多个模块中使用。这个高度可重用的模块通常被提取为公共代码库，例如验证模块。当它想要扩展功能（添加 sms 验证代码登录等）时，单个代码库的大小只会增加，整个应用程序将需要重新部署。在微服务体系结构中，验证模块可以作为单个服务进行隔离，并可以独立运行、测试和部署。
遵循微服务拆分代码的概念，可以大大减少模块之间的耦合，横向扩展将变得容易得多，适合目前云计算的高性能、高可用性和分布式开发环境。
独立的部署
微服务架构 模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。
最后，微服务架构模式允许每个服务独立扩展。您可以根据每个服务的大小部署您的需求大小。您甚至可以使用更适合您的服务资源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署 内存数据库 。
微服务有哪些不足？
微服务应用程序是 分布式系统 ，这带来了固有的复杂性。开发人员需要选择并完成RPC或消息传递之间的进程间通信机制。更重要的是，他们必须编写代码来处理本地的故障，如消息传递缓慢或不可用。当然，这并不困难，但在微服务下，这一技术要比在单片应用中使用语言级别的方法或进程调用更加复杂。
微服务的挑战来自分区的数据库架构。商业交易通常会同时更新多个业务子实体。对于单一应用程序来说，是很容易的，因为只有一个数据库。在微服务架构应用中，需要更新不同服务使用的不同数据库。使用分布式事务并不一定是一个好的选择，这不仅是因为CAP理论，而且还因为今天高度可扩展的 nosql 数据库和消息中间件不支持这个要求。最后，您必须使用最后的一致性方法，这对开发人员提出了更高的要求和挑战。
测试一个基于微服务架构的应用也是很复杂的任务。对一个单体式web应用，测试它的REST API，是很容易的事情反过来，同样的服务测试需要启动与其相关的所有服务（至少是需要这些服务的stubs）。同样，采用微型服务架构的复杂性不可低估。
微服务架构模式应用的变化将影响多个服务。例如，如果要完成一个情况，需要修改服务a、b和c，而a依赖于b，b依赖于c。在整体应用程序中，您只需要更改相关模块、集成更改并部署它们。相比之下，微服务架构模型需要考虑相关变化对不同服务的影响。例如，您需要更新服务c，然后是b，最后是a，幸运的是，许多更改一般只影响一个服务，很少有更改需要协调的多服务。
部署微服务应用程序也是复杂的，分布式应用程序只需在复杂的均衡器后面部署自己的服务器即可。每个应用程序实例都需要配置基本服务，如数据库和消息中间件。相比之下，微服务应用程序通常由大量的服务组成。
微服务怎么做逻辑分层
假设微服务里面有几个服务，分别是订单，商品，用户。
如果客户端向查看 “我的订单” 这么一个接口;如果客户端假定是 PC 端，就需要请求三次接口，分别对接订单，商品，用户三个服务，分别拿完三次调用数据，再将三次调用数据进行整合输出展示。
要知道 PC 调用后端服务是走外网，这无疑大大增加了网络的开销，而且让 PC 端变成更为复杂。
假定在中间加多一个层为聚合服务层，即对网络开销进行减少，因为微服务内部是通过内网进行数据传输，也让 PC 端的业务变得比较简单。
图中的 “PC 聚合服务” 也是一个微服务，只不过它是属于聚合服务中间层，我们将为微服务进行逻辑划分，分为 2 个层：
①微服务基础服务层
基础服务一般属于互联网平台基础性的支撑服务，比方说，电商网站的基础服务有订单服务，商品服务，用户服务等。
这些都属于比较基础和原子性，下沉一个公司的基础设施的低层，向下承接存储，向上提供业务能力，有些公司叫基础服务，中间层服务，公共服务，Netflix 成为中间层服务。我们暂且统称为基础服务。
②微服务聚合服务层
已经有了基础服务能提供业务能力，为什么还需要聚合服务，因为我们有不同的接入端，如 App 和 H5，PC 等等，它们看似调用大致相同的数据，但其实存在很多差异。
例如 PC 需要展示更多信息，App 需要做信息裁剪等等。一般低层服务都是比较通用的，基础服务应该对外输出相对统一的服务，在抽象上做得比较好。
但是对不同的外界 App 和 PC 的接入，我们需要作出不同的适配，这个时候需要有一个层去做出聚合裁剪的工作。
例如一个商品详情在 PC 端展示和 App 端的展示，PC 可能会展示更多的信息，而 App 则需要对信息作出一些裁剪。
如果基础服务直接开放接口给到 PC 和 App，那么基础服务也需要去做成各种设配，这个很不利于基础服务的抽象。
所以我们在基础层之上加入聚合服务层，这个层可以针对 PC 和 App 做成适当的设配进行相应的裁剪。
