引入Artifactory之后，相当一段时间还处于验证阶段，单集群解决方案会比较普遍。随着运维的成熟度和团队对Artifactory的接受度不断提升，各地域给单集群Artifactory带来的压力会越来越大，此时多地域高可用方案会逐步实施。
解决的问题：
制品仓库系统有很多，例如Artifactory、Archiva、Sonatype Nexus、Eclipse Package Drone，其中Artifactory拥有很多强大的企业级特性和人性化的用户接口，拥有众多客户群。很多大型的公司都在使用它，通过以下的Google趋势图可以看出，它越来越受青睐。功能对比在此：Binary Repository Manager Feature Matrix
本文将尝试在阿里云上搭建Artifactory集群。
官方正版license，3个 License 25900美元(16.7万人民币)一年，贵的离谱。本文以实验学习为主使用最新破解版4.7.4，破解也非常容易就不赘述了。商业用途，请使用正版。
Artifactory集群需要以下硬件设备：
Don’t start with a monolith
… when your goal is a microservices architecture
如果你的目标是微服务，就不要从单体应用开始。
In the last few months, I’ve heard repeatedly that the only way to get to a successful microservices architecture is by starting with a monolith first. To paraphrase Simon Brown: If you can’t build a well-structured monolith, what makes you think you can build a well-structured set of microservices? The most recent – and, as usual, very convincing – rendering of this argument comes from Martin Fowler on this very site. As I had a chance to comment on an earlier draft, I had some time to think about this. And I did, especially because I usually find myself in agreement with him, and some others whose views I typically share seemed to agree with him, too.
最近几个月里，我多次听说要成功架构微服务的唯一方法是从单体应用开始。用Simon Brown的话说：如果你不能构建一个架构清晰的单体应用，你怎么能相信你能构建一个架构清晰的微服务呢？最近在Martin Fowler的个人网站上对此话题也有所讨论。
I’m firmly convinced that starting with a monolith is usually exactly the wrong thing to do.
Starting to build a new system is exactly the time when you should be thinking about carving it up into pieces. I strongly disagree with the idea that you can postpone this, as expressed by Sam Newman, again someone I agree with 95% of the time:
I remain convinced that it is much easier to partition an existing, “brownfield” system than to do so up front with a new, greenfield system. You have more to work with. You have code you can examine, you can speak to people who use and maintain the system. You also know what ‘good’ looks like - you have a working system to change, making it easier for you to know when you may have got something wrong or been too aggressive in your decision making process.
— Sam Newman
API版本控制多用在产品发布之后需要根据新需求对部分API做出相应的调整，是在系统维护过程中比较困难但势在必行的任务。不管采用何种版本控制策略，引入新的API版本都会带来一定量的维护成本。最好的API版本化，就是没有明显的版本。在对已发布的服务进行变更时，要尽量做到兼容，其中包括URI、链接和各种不同的表述的兼容，最关键的就是在扩展时不能破坏现有的客户端。
随着移动业务的不断创新，基于位置服务的需求逐渐增多。比如美团搜索附近的美食，嘀嘀打车搜搜附近的司机等。支撑这一业务最主要的就是LBS(基于位置的服务)，特别是嘀嘀打车的业务尤为突出，司机与乘客不断更新的坐标地址，从一大堆无关的坐标地址内找出一定范围内所有的司机，这无疑对服务器承载力带来巨大的挑战。
先比较一下不同的解决方案。最后讲解一下如何使用52位的GeoHash集成Redis实现此需求。