如何构建微服务？
在构建微服务时，我们必须考虑；
我认为将这些视为单独的问题很重要，即使在确保您的业务逻辑组件不依赖于传输选择，甚至根本不依赖于传输的程度上也是如此。
我们如何确定微服务的大小？
您系统中的业务组件是；
- 小的可部署代码和数据单元。
- 根据您的要求对业务用户有意义的功能。
组件的正确大小取决于您选择微服务的原因。
- 是否扩展了开发工作量，从而允许每个开发人员都尽可能独立地工作。 （开发人员效率）
- 是否可以扩展硬件的利用率，从而使每个CPU或服务器都能尽可能独立地工作。 （计算机效率）
通常，我们希望每个组件中正在开发的组件数量可能是开发人员数量的函数，而这些组件的已部署实例的数量很可能是CPU或服务器数量的函数。
除非您知道性能是关键问题，否则我将确保您优先考虑开发人员的效率。 我希望对于大多数项目来说，每个开发人员都有大约一到三个业务组件。
我们如何部署组件？
微服务是带有运输选项的业务组件。 我认为选择可选的运输方式是一个重要的考虑因素，因为业务要素不应受到选择运输方式的太大影响，而没有运输方式在项目的不同阶段会有所帮助。
在编写单元测试和调试业务组件时，无需涉及传输。 如果要查看两个组件之间如何交互，则应该能够创建一个简单的程序来创建两个或多个组件，并从IDE运行并查看它们如何在同一线程中协同工作。
分配水平
您需要考虑不同级别的分布。 初，只要确保可以分发这些组件，就可能根本不需要传输。 后来，您需要细粒度的分布图或过程粒度的分布图，但是随着时间的流逝，随着组件的成熟，您将不需要管理大量服务的开销，并且您希望能够合并它们。
- 实例处于相同的逻辑任务中，并且彼此之间没有任何层连接在一起。
- 实例位于单独的逻辑任务中，但是共享相同的线程池[ 1 ] 。
- 实例位于单独的线程池中，但进程相同。
- 实例位于单独的OS中，但位于同一台物理计算机上。
- 实例位于同一数据中心，但计算机不同。
- 实例位于不同的数据中心。
对于性能，我赞成＃1，＃2和＃3，对于测试和开发，我赞成＃1和＃3，而对于高可用性，则需要＃5和＃6。
如果您不需要在用于HA的计算机之间分配实例，则希望您的实例不比所需的独立。 期望的分离度可以随时间变化。 初将组件添加到生产中时，能够部署，升级和重新启动该组件而不影响系统的其余部分会很有用。 但是，随着组件的稳定和变化不大，您可能希望减少管理该服务的开销，并将其包括在具有多个服务的流程中。 您可能会发现该服务使用了少量的CPU，并且可以将其与其他服务合并到同一线程池中。 如果事实证明它与另一个实例的交互是高度耦合的，则可以将它们作为单个组件连接在一起。
迁移到微服务
假设您拥有一个整体，如何迁移到使用微服务？ 您是否需要重新设计整个解决方案？ 没有。 迁移比听起来容易，因为微服务的主要优势在于将服务投入生产时处于开发的早期阶段。 任何在您的整体中运行良好的东西，都留在那里。 在开发和成熟期间，您需要添加或进行重大更改，将其移至其自己的服务中的所有内容。 您可以将其想象成一个整体的，行星大小的微服务以及围绕它的许多较小的卫星微服务。
灵活的设计
您希望开发人员能够高效地工作，并且您的系统能够充分利用服务器。 您不希望一开始就做出选择，将自己束缚在一个解决方案中，以后您会后悔。 如果您使用灵活的设计，则可以大程度地提高生产力，并确保使用微服务来扩展它们对您的帮助，但不会因过度使用该技术而带来不利影响。
进一步阅读
要了解更多看到我对其他职位微服务
翻译自: https://www.javacodegeeks.com/2016/07/goldilocks-microservices.html