随着我们需要治理的微服务数量越来越多，我们必须开始着手解决服务间通信的复杂性问题，而Service Mesh（服务网格）的出现恰逢其时，作为基础设施层，它能够以透明代理的形式提供安全、快速、可靠的服务间通信。
那么在实施Service Mesh前，我们需要考虑哪些问题？
团队准备好上手Service Mesh了吗？
任何新技术、新工具的实施、使用和维护，都有一定学习成本，同时我们需要做好充分的理解和准备，确保这项投入是有意义的。例如我们管理的分布式应用存在大量不同的微服务间服务调用，那么Service Mesh值得一试。
目前的问题是什么？
目前遇到了哪些问题？管理分布式应用的一大痛点在哪里？是可观察性、服务依赖，还是安全性？如果答案是肯定的，那么Service Mesh会帮的上忙。
需要支持哪些平台？
应用在哪里运行？除了容器管理平台之外，是否需要把我们关注的服务网关服务连接到不在Service Mesh上的其他服务？
服务现在的可观察行如何？
Service Mesh最容易实现的好处是深入到服务通信中的可见性，这一点对于大多数企业IT来说都很重要，却是一个容易被忽视的问题。
有哪些Service Mesh功能是已经实现了的？
如何利用Service Mesh也是需要考虑的。通常的情况是，我们已经有了一些解决方案，例如解决负载均衡问题等等。已经存在的解决方案如何与Service Mesh集成，或者弃用原有解决方案，用新的替换？
团队怎样进行分工？
开发团队是否愿意自己来管理代理配置？还是由运维团队进行统一的管理？我们应该确保实施Service Mesh后的分工是高效而有意义的。
集中式还是分布式？
根据部署的规模和复杂程度，团队是倾向于采用基于host-based代理池，或者在担心Service Mesh下sidecar模式的潜在复杂性？哪些因素会影响我们的决策？
团队希望得到怎样的支持？
开源社区支持是否能够满足团队需求？对于快速迭代的产品功能和标准有多大容忍度？是否需要商业支持？在生产中，这些注意事项很重要。
以上几点仅作为抛砖引玉的思考，对于不同的组织，情况肯定是不尽相同的。
进一步了解Service Mesh解决方案，获取开源和商业支持，可访问Rainbond官网并与好雨工程师取得联系。
关于Rainbond
Rainbond是一款以应用为中心的开源PaaS，由好雨基于Docker、Kubernetes等容器技术自主研发，可作为公有云或私有云环境下的应用交付平台、DevOps平台、自动化运维平台和行业云平台，或作为企业级的混合云多云管理工具、Kubernetes容器管理工具或Service Mesh微服务架构治理工具。
- Rainbond项目网站
- 试用Rainbond公有云
- 注册或使用Demo账号/密码登录：rainbond-demo/rainbond-demo
- Github
- 码云
- 文档
- 微信群: 添加微信“zqg5258423”并接受邀请入群