微服务架构作为新兴领域的架构模式，已步入产品化形态，与容器化、集群等一起成为了当下热点。而微服务、Docker、kubernetes 之间的关系，究竟这三者之间是什么样的关系，分别能在微服务领域发挥什么作用，却常给入门的读者和用户带来些许迷茫感。
本文使用一个简单的普适性的微服务示例，从业务场景入手，到微服务架构设计、实现、容器化、集群部署、压测、弹性伸缩、资源控制，端到端以最直白的方式演示了这三者的关系，会给读者带来不一样的真切的理念体验和感受，增强对系列概念的理解。
普适性微服务化示例
为了读者能更容易了解 ServiceComb 微服务框架的功能以及如何用其快速开发微服务，所以提供大家耳熟能详的例子，降低学习曲线的同时，增加趣味性，加深理解。
本文中假设我们成立了一家科研公司，处理复杂的数学运算，以及尖端生物科技研究，并为用户提供如下服务：
-
黄金分割数列计算
-
蜜蜂繁殖规律 (计算每只雄蜂 / 雌蜂的祖先数量)
但是我们如何将公司的这些强大运算能力提供给我们的消费者呢？
首先我们通过认证服务保障公司的计算资源没有被滥用， 同时我们对外提供 Rest 服务让用户来进行访问。下面的视频展示具体的服务验证调用的情况。
业务场景
让我们先对业务场景进行总结分析
1. 为了公司持续发展，我们需要对用户消费的运算能力收费，所以我们聘用了门卫认证用户，避免不法分子混入。
2. 为了提供足够的黄金分割数量运算能力，我们需要雇佣相应的技工。
3. 为了持续研究蜜蜂繁殖规律，公司建立了自己的蜂场，需要相应的养蜂人进行管理研究。
4. 为了平衡技工、养蜂人、和门卫的工作量和时间，我们建立了告示栏机制，让当前有闲暇的人员发布自己的联系方式，以便我们能及时联系技能匹配的人员以服务到来的用户。
5. 因为运算能力成本高昂，我们将运算项目进行了归档，以便未来有相同请求时，我们能直接查询项目归档，节省公司运算成本。
6. 面对上述复杂的场景，我们又聘用了部门经理来管理公司成员和设施
7. 最后，当公司日益壮大，用户数量暴涨时，我们还需要招聘更多技工、养蜂人、和门卫，所以增加了人力资源部门
公司结构 (系统架构)
到现在业务场景已经比较清晰，我们把上述职务部门和设施画成公司组织结构图。
现在公司组织结构已经完整，让我们着手搭建相应部门。
本文转载自微服务蜂巢公众号。
评论