DockerInfo在构建新的项目时应该总会考虑SOA或者微服务的方式。无论是新建还是重构。都请注意：考虑仍保持开放的选择不采取这种方法。在读完本文之后，关于是否建立多个小部件,你将会有一个更好的方法。
这篇文章是假定你有一些软件架构和服务方面的经验。我将谈一些微服务或SOA，同时在你的项目中该如何做。
是微服务？还是SOA?都用？都不用？
有人说，微服务与SOA差别很大。也有人说，微服务与SOA有相同点，但是是SOA的下一代，轻量级和less-enterprisey什么的。
完美构架不存在
你已经知道了没有完美的软件构架方法。Microsoavices可能不适合你的项目，甚至你的公司。什么是microsoavice呢？首先，我想说明这个两个简单的关键点：
- 细粒度的责任
- 内置的容错
他们是所有项目的基础，无论你的项目是大还是小。
细粒度的责任
Microsoavices可以是单任务或单个域。下面是一个单任务microsoavice的一个例子。
所有的项目不仅包括业务逻辑和应用领域。总有一些会涉及普通工具。我曾经在一个需要将RTF文件转换为HTML的项目。我们使用了一个库，这是很容易的。另一方面，在更新库时要求我们重新部署应用程序的所有实例。部署是自动化的，同时我们不需要发送新版本给客户，但是对于只有三个人的团队维护几十个实例是要花点时间的。
将相同库封装到一个独立的应用中然后去监听所有的HTTP请求，把它变成一个microsoavice是必要的。总之，从那天起，更新该库只是一个再部署一个单独的组件的事（只要API保持稳定）。
除了单任务microsoavices，还有足够多的用例覆盖应用领域，而不只是单一任务的。拿一个购物车的例子来说。
- 添加商品到购物车
- 删除商品
- 更改商品数量
没有人为这些任务创建单独的服务认真考虑过,这就是为什么它是细粒度的。
内置容错
进程内的方法调用,与外部组件间的调用替换。最大的区别在于，外部调用更容易失败。它需要关注,但适当地考虑了它使整个系统更加稳定和容错设计。
容错真的是一个核心问题。早期把它弄对是microsoavices成功的关键。
问题
构建，部署和维护许多小的，独立的组件组成的系统也带来了许多的问题。你不仅要面对容错的问题，还包括这些问题：
- 配置（我在哪里实现这一服务？）
- 监控（提供哪些服务？）
- 部署（多少实例吗？在哪些主机上运行它们）
- 测试（在服务呼叫失败的情况下怎么办？）
- 等等问题
测试和部署应该考虑到持续集成和部署工具可用。中央microsoavice环境的配置可能是一些可以通过使用一些ESB-like工具解决。
似乎有一切的解决方案，你只是不太满意。老实说，我认为我们没有完全到那一步，当涉及到的工具。将来会带来很多很好的工具，使构建，部署和维护microsoavices容易得多。
心态
从我自己的经验来看，我可以说microsoavice不只是关乎技术问题，这真的是还有一些关于心态问题。
如果你担心因为没有单一故障的服务增加的失败的概率，那么你可能需要重新考虑一下了。如果你看到那些小的组件帮助你降低失败的机率，你可能就能很快解决。
不要忘了你是一个开发人员。确保他们用mircosoavices的思想解决问题。我将在以后的工作中,microsoavices如何改变和提高开发人员的工作。
我的经验
我做软件开发近十年了。那段时间我的工作是不同类型的项目。我做了大约90％的网络用的东西Java和JavaScript，以及一些C＃.NET，Visual Basic中（预DOTNET），Perl，PHP，Python等等，我做了几年的资深开发人员和架构师，也没遇到过一个人处理从开发到部署和维修的团队。
回想起来，我做了一些项目,一些人会从microsoavice方法中真正受益,一些人可能还没有。我做过一个必须用SOA的项目，非常的不实用，这就是为什么我想写的务实的话题，并从实用角度看待项目。
