微服务?
微服务（Microservices）是一种分布式架构设计理念，是多个功能明确、单一的服务独立部署并且协同工作的服务组，其中每个服务都是一个独立的实体，可以独立部署在PaaS平台上，也可以作为一个独立的进程在主机中运行，服务与服务之间通过API访问，其中一个服务变更不会影响其它服务。
0b46f21fbe096b63144c31c406338744eaf8acc9.jpg
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
现状
微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
34fae6cd7b899e5104e4ddaa4aa7d933c8950d21.png
企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中，微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件，它们可以更加容易升级和扩展，理论上是这样。
微服务的好处
- 解决技术异构问题（服务和服务之间通过API网络通信，可以使用不同的语言和技术开发不同的服务）
- 快速迭代新技术（服务功能单一且独立，可以更新）
- 拓展方便
- 部署方便
- 服务复用度高
- 便于维护
服务建模
服务建模的两个指导原则：
- 高内聚：关键是找出问题的边界，把相关的问题放在同一个服务中。
- 松耦合：修改一个服务不需要修改另一个。
过早的将一个系统划分成微服务的代价非常高，尤其是在面对新领域时，将一个已有的代码库划分成微服务会比葱头开始建设微服务要简单的多。
分解单块系统
分解巨大无比没人感动的单块系统，首先要做的是理清代码库，找到接缝。
分解系统带来的好处：
- 加快以后系统开发速度
- 划清了团队结构
- 增加安全审计功能后，保障安全性
- 利于开展新技术
部署
跟传统服务的部署并没有太大的不同，无非是微服务的短平快，加快了CI（持续集成）的速度。如果将微服务打包为docker镜像，使用Jenkins、ansible、puppet等技术来部署微服务可以实现部署自动和效率的显著提高。
网友评论