就我个人而言，我觉得微服务架构应该满足以下几个特征：
- 整个系统被分为多个业务功能相对独立的一体化架构（Monolithic Architecture，或称单一化架构）的应用程序（也就是所谓的“微服务”），每个微服务通常遵循标准的分层架构风格或者基于事件驱动的架构风格，能够对自己相关的领域逻辑进行处理，使用本地数据库进行数据存储，并向上层提供相对独立的API接口或者用户界面。每个微服务还可以使用诸如缓存、日志等基础结构层设施，但如果是与其它的微服务公用这些设施，则该基础结构层设施需要满足下面的第三条特征
- 各个微服务之间可以使用以下方式进行通信（参见：http://howtocookmicroservices.com/communication/）
- 同步方式：最为常见的是基于RESTful风格的API，也可以是跨平台、跨语言的Apache Thrift IDL
- 异步方式：使用轻量级的消息通信机制，比如RabbitMQ、Redis等
- 整个系统是“云友好”（cloud-friendly）的。所谓的“云友好”，是指：
- 针对每个微服务，都应该避免单点失败的可能。例如针对一个系统中某个微服务A，需要有至少两个（或以上）的运行实例，并由API网关（API Gateway）或者负载均衡器（Load Balancer）根据一定的规则（比如各个A的运行实例的健康程度等）将来自客户端的服务请求分配到任意一个A的运行实例上完成处理
- 针对每个微服务，管理员可以根据一些特定的实时技术指标对这些应用程序的部署进行调整。例如，购物网站的查询服务负载明显要高于订单管理服务，那么管理员可以根据实际情况，增加查询服务的部署量（比如部署3个查询服务的实例），同时减少订单管理服务的部署量。与整个系统单一采用一体化架构相比，这样做的好处是显而易见的，它能够充分利用云端服务器资源，使得每个微服务都能够运行在合理的资源配置状态下，减少资源浪费
- 公有基础结构层服务设施也应该满足避免单点失败的条件，例如数据库服务需要配置Replication/Clustering，消息队列也需要使用类似的fault tolerance策略
- 基于“云友好”的需求，衍生了一大堆的部署和运维问题，比如微服务本身的配置模式（每台机器配置多个实例？还是每台机器配置一个实例？还是每台虚拟机配置一个实例？又或者是将实例配置到类似Docker这样的容器中）？消息队列如何配置才能支持同一个微服务的多个实例不会重复处理相同的消息？基于RESTful的通信如何让客户端找到动态改变的API地址？等等。我想，这些问题并没有一个特定的答案，还是需要根据实际情况来进行判定
相比传统的一体化架构系统，微服务架构系统有着以下一些优势：
- 每个微服务都相对较小，这样更加便于开发和调试
- 每个微服务都相对独立，这样不仅可以使开发人员仅关注在某个业务处理部分，而且还可以针对每个微服务自己的特征，采用不同的技术实现（比如部分微服务使用C#实现，部分使用Java或者Python等）
- 这种独立性使得微服务在容错隔离方面也有很好的表现：比如某个微服务出现了crash等问题，不会导致整个系统不可用，这符合BASE（Basically Available, Soft-state, Eventually consistency）理念
- 由于相对独立，微服务架构的设计能够更方便地部署到云环境中
- 微服务的独立性还为敏捷开发提供了很好的支持。比如每个服务都可以单独开发单独部署，同时项目团队还能根据成员本身的技术专长来平衡开发和测试资源
当然，它也有一些不足：
- 开发人员需要应对由分布式架构带来的复杂性。比如如果微服务间采用异步的消息通信机制进行通信，那么就需要遵循由这种消息机制所引入的开发模式（创建消息处理器Message Handler，转发消息等）。此外，这种架构为测试工作也带来了很多不方便的因素，例如当某些测试用例（Test Cases）需要涵盖多个微服务的业务时，就需要关注弱一致性分布式事务的执行结果，而这往往是比较复杂的。更进一步，这种测试工作还需要多个团队的协调才能顺利进行，当各个团队分布在全球各个国家各个地区时，协调工作更是变得复杂甚至难以进行
- 在生产环境中部署、安装和管理基于微服务架构的系统也不是件容易的事情。这需要客户方有着较强的专业技术背景和解决问题的能力。当然，一种更好的方式是以SaaS的方式直接将服务提供给消费者
- 较多的资源消耗。出于隔离和容错需要，微服务有可能被部署为N个实例，每个实例运行于独立的虚拟系统中。假设部署策略不当造成系统资源存在一定的浪费，那么这种浪费也有可能被扩大N倍
有关微服务架构的内容暂时就写这么多吧，微服务架构现在比较火爆，大家也可以直接上网查阅相关资料，英语比较好的朋友建议直接上英文网站去搜索学习，有很多精华文章和精彩讨论。架构本身就是仁者见仁智者见智，不同的人有不同的理解，产生了不同的观点，有些观点可能在有些场景下更为合适，但换个场景又体现了它的弱势。但不管怎样，我想说的是，无论选择什么架构，它总有优缺点，架构设计的难处就在于如何选择最为合适的模式、方法、技术来完成一整套系统开发的解决方案。更多情况下，整个应用系统更有可能是融合了多种技术多种架构风格的“生态圈”。对于你现在正在开发的项目，或许使用经典的三层架构最为合适。
