19｜如何将模型实现为微服务？

回答课后题： 产品化意味着要有打磨产品的意识，从以下角度展开yy。 1.从需求角度。做产品化就得去思考和挖掘产品背后的目标用户是谁，以及他的真实诉求是什么。想明白解决谁的什么问题，对自己的产品做合理的定位。拒绝平均化，不做满足一切的产品。（讲人话就是主动去定义自己的产品，发现支点找准边界） 2.从服务的角度。服务是产品重要的组成部分，产品化意味着我们也需要具备与之匹配的服务能力。比如，成立答疑小组，制定和监管答疑考评制度与指标。将经验变成流程，流程变成工具，沉淀知识库，让服务质量从依赖个人英雄转向依赖团队沉淀。 3.从运营角度。现在的软件服务相对以往有个很大的转变，从交付式产品(卖软件)向运营式产品转型。而运营式产品，交付只是开始，随后需要一天不停的成长直至死亡。这就需要我们的软件产品具备快速支持迭代的扩展性（1～10），我们的开发团队具备抽血重构的能力与魄力（10～1）。 4.从定价角度。一个产品怎么可以没有定价（哪怕你是内部产品也要有）。而且我们不仅要给产品设定价格，还要赋予它价格歧视的特性。以内部产品为例，任何需求不管是使用已有能力的调用还是需要新特性支持的迭代，都需要需求方证明能带来达标的价值(价格)才允许接入/排期。对于核心系统与旁支系统，提供不同限流阀值（价格歧视，同等价格买到的量不同）。对于战略目标提供优先排期的特权（价格歧视，同等价格支持的优先级不一样）。

产品化要更多考虑不同版本之间的兼容性

服务间通信是否可以认为grpc之流的IDL比REST是更好选择？毕竟也跨语言且有一定性能优势。如果说不如REST的就是离be the web 远点

行业内做伪微服务的人多，而做真微服务的人少。很多问题不值得去解决，因为没有将问题定义清楚。而一旦明白什么是真微服务，大多问题都变得不言自明。👍

原来我一直在傻微服务里

产品化的服务意味着要先有产品。在有追求的人心目中，产品相当于自己的事业或孩子，找到生态位，定义它的价值、边界，形成可行的发展规划（包括版本计划），配置合适的资源在有效的管理之下逐步发展。用内部通俗的一句话来说，就是要管杀还要管埋，不是做一阵子就甩手给运维团队或他人（传统行业企业内部这种情况尤其严重）。

微服务产品化后。如果前端应用需要某些特性，可能就需要这个服务的团队去做修改、发布后才能继续。这样增加了交付周期，降低团队敏捷性。

产品化的服务带来的挑战。需要服务保留旧版本特性，这样如果设计不合理重构的时候，可能需要保留很久旧逻辑，需要有一个逐步淘汰旧版本的机制。

傻服务，不太明白。 我们是物流服务，对接不同的第三方物流供应商。 而我们正在做的就是把所有对接流程都标准化、数据化，然后通过编排来自动对接。 这种是傻服务吗？

通过本篇文章，我有个一个疑问想问一下老师： 微服务是以服务为边界，可以自行选择自己的语言，独立维护自己的数据源。有个问题，就是产品的需求当涉及到多个微服务团队来支撑产品实现的时候，什么样的方式能高效的完成一次次的需求评审和产品迭代呢？