“微服务”架构是近期软件应用领域非常热门的概念。那什么是微服务？

简单的说，微服务架构就是将一个完整的应用 从数据存储开始垂直拆分成多个不同的服务，每个服务都能独立部署、独立维护、独立扩展，服务与服务间通过诸如REST、API的方式互相调用。

传统IT架构面临的一些问题以及云计算及互联网公司大量开源轻量级技术不停涌现并日渐成熟 ，这就催生了新的架构设计风格 – 微服务架构的出现。

（简单描述一下轻量级技术涌现：

 1、轻量级运行时技术的出现(node.js等)；

 2、新的方法与工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)；

 3、新的轻量级协议(RESTful API接口, 轻量级消息机制)；

 4、服务平台化(PaaS)： 云服务平台上具有自动缩放、工作负载管理、SLA 管理、消息机制、缓存、构建管理等各种按需使用的服务；

 5、标准化代码管理：如Github等；）

微服务架构的优点：

  1. 每个服务都比较简单，只关注于一个业务功能。
  2. 微服务架构方式是松耦合的，可以提供更高的灵活性。
  3. 微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
  4. 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
  5. 微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

微服务架构的缺点：

     微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。

  1. 运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。
  2. 必须有坚实的DevOps开发运维一体化技能：开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。
  3. 隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
  4. 代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。
  5. 分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
  6. 异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
  7. 可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

   关于微服务架构的取舍：

  1. 在合适的项目，合适的团队，采用微服务架构收益会大于成本。
  2. 微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。
  3. 需要避免为了“微服务”而“微服务”。
  4. 微服务架构引入策略 – 对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。

现在在业界基于微服务的实践方法有两种，一种是dubbo，一种是springcloud

未完，待续。。。。